FPGA Prop1 - feature request - Propeller block symbol (edit 3 - solved)
pik33
Posts: 2,366
What we have now is an Verilog code wrapped in AHDL top layer
A request (of course I can do it myself but with no AHDL knowledge it will take some time to decode and understand these top files):
- a BDF file with the Propeller inside
instead of top file with I/O pins added, so we can place it on a Quartus block diagram editor and connect its IO pins to anything we want - anything we have available on DE2-115 - instead of its GPIO pins.
Edit: partially solved, I have now a block with a propeller inside by simply creating a symbol file from a "top.tdf". It still needs some work (I have to rename some files and remove assignments to make my own "top" of quartus project)
Edit 2: removed "solved" icon because it is not solved.
I renamed "top.tdf" to "prop.tdf", then, inside a tdf file I changed subdesign top to subdesign prop.
Then I made a symbol file.
Then I started a new project, made a new top entity as a bdf file, put the prop symbol on it, connected inputs and outputs.
And when compiling this, I got:
Error (10170): Verilog HDL syntax error at dig.v(89) near text "+"; expecting "="
I didn't touch any of .v files.Lines 87..90 of dig.v are
where line 89 is for (i=0; i<8; i++)
So, now I don't understand this and feature request is still valid.
Edit 3. Solved. I have a Propeller with red LED signalling working cog instead of green one and reset on key0
Solution was simple: it uses System Verilog, not a plain Verilog. So after all renaming I described above, I had to go to Assignments->settings->verilog input and switch it to System Verilog..
A request (of course I can do it myself but with no AHDL knowledge it will take some time to decode and understand these top files):
- a BDF file with the Propeller inside
instead of top file with I/O pins added, so we can place it on a Quartus block diagram editor and connect its IO pins to anything we want - anything we have available on DE2-115 - instead of its GPIO pins.Edit: partially solved, I have now a block with a propeller inside by simply creating a symbol file from a "top.tdf". It still needs some work (I have to rename some files and remove assignments to make my own "top" of quartus project)
Edit 2: removed "solved" icon because it is not solved.
I renamed "top.tdf" to "prop.tdf", then, inside a tdf file I changed subdesign top to subdesign prop.
Then I made a symbol file.
Then I started a new project, made a new top entity as a bdf file, put the prop symbol on it, connected inputs and outputs.
And when compiling this, I got:
Error (10170): Verilog HDL syntax error at dig.v(89) near text "+"; expecting "="
I didn't touch any of .v files.Lines 87..90 of dig.v are
genvar i;
generate
for (i=0; i<8; i++)
begin : coggen
where line 89 is for (i=0; i<8; i++)
So, now I don't understand this and feature request is still valid.
Edit 3. Solved. I have a Propeller with red LED signalling working cog instead of green one and reset on key0
Solution was simple: it uses System Verilog, not a plain Verilog. So after all renaming I described above, I had to go to Assignments->settings->verilog input and switch it to System Verilog..
Comments
Now I will try to run this on DE1-SoC with Cyclone V.
Still have no solution to program this thing - I have no PropPlug. DE2-115 has an RS232 but only Tx and Rx signals are connected
All important details are in verilog files. Maybe we can make active these mul and div instructions?
These AHDL files are top layer files which connects all of parts into one whole system.
How does a Cyclone IV build compare with Cyclone V, for the FPGAs used on the obvious boards ?
Logic/Ram/Speed ?
For targets other than Altera, it would make sense. For Altera, it is optional.
I built and preliminary run it on DE1-SoC. Cyclone V has ALMs instead of LEs. ~7900 C5 ALMs vs ~16000 C4 LEs. It should run 1.5x faster with Cyclone V (150 MHz? its internal memory can work >300 MHz and PLLs >600 MHz), but I will have no data until I solve a lacking PropPlug problem. (maybe today)
What do the speed report files say ?
Chip did a quick build for C5, and reported this
["It turns out that even though this Cyclone V -A2 part has 25k LE's, the P8X32A takes 85% of them! That's 33% more LE's than it takes on the Cyclone IV. Plus, it took 3x longer to compile. Oh, and Fmax is still over 80MHz, but slower than Cyclone IV."]
Maybe that is just a settings issue, but more CyV s CyIV build reference compares would be useful to check.
If you have converted your .v or .vhdl or anything to .bsf block symbol file, you have a block symbol you can use in the graphic editor. And, yes, it is a block you can add to your design.
We can make a block from a cog, a hub, etc - any entity can be a block - and then connect them in the quartus graphic editor instead of doing this in a top AHDL or other text description file.
Pik33 how are we going to solve this ongoing PropPlug issue for you? Did you make up and try the transistor / rs232 circuit? That should work. Failing that, do you have any other FTDI based USB to serial modules in any form? Or CP2102's or something? Anything?
Both the BeMicro and the DE0 have FT245's on them, for their usb interface. It would be really useful to be able to use these for communications, post altera programming, like we often do with prop plugs. I don't know whether this is possible, but if it was it would lower the barrier for all of us (well those without spare propplugs anyway).
Yeah I know what you mean, and they don't seem to show the FT245 connections on the corresponding schematics which is a pity. I suspect it might be just for some JTAG bitbanging. Maybe they think that's their secret sauce! LOL.
I am solving this right now. DE2-115 has RS232 input. I only need an RS232 cable with DTR (done), RS232 port on mainboard (there is one) connected to a DB9 slot (I am connecting this right now) and some verilog code to make a reset pulse for the Propeller (as soon I connect all of this RS stuff)
Without a propplug. All you need is an RS232 female(PC)-male (DE2-115) cable with pin connection 2-2, 3-3, 4(PC)-7(DE2-115), 5-5
Pulse circuit was not needed, I simply connected UART_RTS to RESn
Let's start playing now and check if it is programmable...
First... simply connect some LEDS to some Px and blink them in Spin
Yes, but I don't know how to connect a AHDL propeller to anything in Verilog. I used to write my modules in verilog, then convert them to blocks and connect them in the graphical editor. It is then easy readable.Blocks can be nested, you may make a big block from some small ones.
And the LED blinks!
The circuit in the picture.
The strange code used for blinking, copied from my first prop experiments:
con delay=40000 pub start coginit (1,@proc,delay) dat proc mov 489,#1 or dira,489 loop3 mov 490,par shl 490,#4 mov 489,#1 mov outa,489 loop djnz 490,#loop mov 489,#0 mov outa,489 mov 490,par shl 490,#4 loop2 djnz 490,#loop2 jmp #loop3I'm going to try and follow your example and build a P1 Block. Not sure why at this point other than it will be good hands on experience working with the tools and Verilog and that's what I need right now. I like your idea of having the blocks to link together especially with all the extra goodies on the DE2.
PM me if you are interested in a PropPlug - I'm sure I have an extra floating around some place. This way you can experience the best of both worlds! Postage to Poland for a small envelope with "gift" on the customs label can't be all that terrible.
To do
... edit... and EEPROM.... there is a eeprom on DE2-115 but it is too small for a prop Maybe it will be possible to write an EEPROM emulator using a flash chip.Or maybe simply buy a 40 pin connector, prototype board and put an real eeprom on it.
And we can then put more than one prop on the design.
I have no idea what you are talking about in detail, not having ever used any HDL or FPGA before, but it sounds like you are making sense.
The sources as released already look like a mess to me as we have two directories of verliog for two different Altera devices/boards with the same Propeller verilog files in both (At least by name if not content). Presumably most of that verilog is the same but some of it is tweaked for the different platforms. I have no idea what the differences are as I have not done a diff on the files yet.
Even without knowing anything about anything this does not look good and clearly does not scale to many platforms and potentially many patches and fixes by many people.
Clearly this needs splitting up into the essential Propeller components and a variety of top level adaptions/configurations for the different platforms that might be used. Whilst we are at it the PASM source code of the interpreter and other bits should be in it's own source directory rather than sitting around at the top level.
If someone who knows how to organize a verilog tree like that for use across Altera, Xylinx and whatever other tools could do that it would be great.
I have the Propeller files on github here: https://github.com/ZiCog/P8X32A_Emulation
In the absence of any better organization you could fork and hack on that. Not that I have any desire to become a P8X32A_Emulation maintainer. (At least my repo has the tabs removed to fix the broken verilog formatting and make it readable
Clear verilog top file is of course the best.
Making a symbol file from it is a matter of seconds and it can run on xilinx too.
3 interesting files is diffferent:
hub_mem.v - only differ by one line, the commented out char-ROM
top.qsf - Different FPGA device specified and different pin assignments.
readme.txt - well.. it mentions how to get each board up and running
The rest of the files can be considered CORE-files.
I am interested, I have the Spartan s3board (with 1000k gates). And I agree with your idea of board specific files.