Glad you got it your board already and working quickly Ariba, and also at 80MHz! Our boards are taking a European vacation on the way to Australia.
Hey did you get some valid timing constraints setup? I have been trying to get that part sorted myself and there appears to be a myriad of various constraint format options/legacy versions SDC vs FDC etc. So I think it often doesn't meet timing without this file being present and correct.
I've been using Synplify (in Linux) and while yes I do see warnings they mainly appeared to be forward declaration types etc and I did get it to map okay. Funny you mentioned LSE as being better as I had compiler issues with LSE but that was with a different codebase which probably still included some System Verilog bits and pieces that upset things, I might have to retry with the newer P1V code that I'm currently using that Magnus had cleaned up for Xilinx use.
Are you sure that the board needs a resistor mod for RTS? A while back I had asked Valentin to add it and his updated schematic shows it already connected via a 10k resistor to P89B pin as well as to the JTAG interface (it does double duty for both purposes). Hopefully this change actually made it into the final board rev so no-one should have to rework the board, at least that was my intent in requesting it originally. I would have preferred DTR but I think he mentioned that was not available on the FTDI part he uses, but having RTS is better than nothing at all.
In some experiments I found that in my case the clock switching logic worked best for meeting timing if you only switch to 80MHz from a lower speed bootup clock (eg. 12.5MHz) using the glitchless DCSC block in the middle of the FPGA and just leave the higher speed 160MHz signal alone (like you did). Clocks seem best driven directly from PLL outputs not via the original P1V clock divider circuit which has problems with timing. Maybe having valid timing constraints could fix that, not sure...
I am considering using the following PLL setup to allow future HDTV (720p) via HDMI and a USB host in P1V software.
First PLL - input 25MHz from external OSC (VCO set to 750MHz)
output 1 - 375 MHz (5x pixel clock for HDMI's 10x output via DDR IO)
output 2 - 75 MHz (HDTV pixel clock, close to official 74.25MHz, Valentin mentioned it work for his setups but YMMV)
output 3 - 12.5 MHz for slow prop clock
output 4 - spare (this can be 750MHz divided by any integer from 2-128)
Second PLL - input 75MHz clock from PLL1 output (VCO set to 480MHz), this PLL input is also pre-divided to 15MHz
output 1 - 160 MHz (fakePLL clock for P1V)
output 2 - 96 MHz (for USB clock to video generator via a P1V counter mod I already made for this previously)
output 3 - 80 MHz (main P1V clock)
output 4 - 30 or 60MHz (I believe this would be needed to allow feedback divider to use a multiple of 15MHz)
So far haven't got it quite nailed down and working fully but I hope this clocking should be possible.
There are some other options for the PLL output for HDMI clocks which could be 27MHz and 135MHz for 480p or 65MHz and 325MHz for 1024x768 resolutions, or possibly 25MHz and 125MHz for somewhat simpler DVI at 640x480. The ECP5 PLL settings are not dynamic so the desired resolution needs to be fixed in each bit file. Having 27MHz could be quite good for doing digital audio over HDMI.
As you say reusing flash after the FPGA switches to user mode should be possible to replace the i2c PROM with a custom booter which is doable - we already did this ourselves for MAX10 internal flash use too. There is a small piece of HW logic required though as you will need to use a custom Lattice component (USERMCLK) to allow the CCLK output to be driven by user logic to control the SPI ROM after FPGA config completes (normally this pin tri-states and is not accessible as regular IO). Lattice config documentation has more details there. I was just reading about that bit yesterday
Actually thinking more about the clocks you could probably take the slow P1V clock from the second PLL output 4 (at 15MHz) and that could free two outputs on the first PLL for allowing a second video resolution (standard VGA). Then the PLL allocation would look like this:
First PLL - input 25MHz from external OSC (VCO set to 750MHz)
output 1 - 375 MHz (5x pixel clock for 720p)
output 2 - 75 MHz (720p HDTV pixel clock, close to official 74.25MHz)
output 3 - 125 MHz (5x pixel clock for VGA output over HDMI)
output 4 - 25 MHz (for VGA pixel clock)
Second PLL - input 75MHz clock from PLL1 output (VCO set to 480MHz), this PLL input is also pre-divided to 15MHz
output 1 - 160 MHz (fakePLL clock for P1V)
output 2 - 96 MHz (for USB clock)
output 3 - 80 MHz (fast P1V clock)
output 4 - 15MHz (slow P1V clock)
I see now the resistor from TDI to P89B in the schematic. It's hard to find in that part of the schematic especially if you have no clue that it could exist
So we don't need to make any hardware modification - that's really great. Thank's for bringig that to Valentin.
I've not done serious timing analysis. I just looked at the max. frequency values that LSE gives after a synthesis. The clk_cog value does not reach 80 MHz, but I get quite different values depending on how I generate the clock. I first used the internal oscillator with some dividers for all clocks and got higher values than with PLL. In practice it seems to work at 80 MHz, but I need to do more tests, especially with counter-PLL and video.
The rcfast clock is somewhat critical for a seamless download from PropTool. I can only download reliable, if the clock is around 12..13 MHz. But I think we can use the internal oscillator for this clock if it simplifies the PLL usage for the other clocks.
I have not thought about HDMI and USB clocks so far. Why not reserve one PLL for HDMI clock exclusively. USB should be doable with a NCO based receiver and transmitter in Verilog (like on P2).
I've tried to use the DCSC block for glitchless clock switching, but always got errors for unknown parameter names. The description in the appnote seems not to match the IP definition in Diamond. Maybe you can say me how the SEL input is called now.
Normally Synplify is the better synthesis tool (more standard) but in this case it produces no working bitfile. It has to do with the RAM generation, it says that the RAM outputs have no load - makes no sense. To my surprise LSE worked immediately and LUT usage is mostly lower with LSE.
For someone like me who is FPGA IQ impaired, would it be possible to buy one of these gizmos and just load the device without synthesis/etc for Prop enhanced development?
I'm hungry for a Prop+ device but don't have time or inclination to to FGPA-specific development or $$$ for the high-end dev kits normally presented here.
I know it's a bit lazy for me to ask this, so please don't judge me too harshly.
Also at first glance, it wasn't clear if it's still possible to purchase the Flea device...
I noticed that the DE2-115 used external chips for USB interface. I haven't figured out exactly why yet...
Seems like FPGA should be able to handle it...
So I had the exact same problems you are seeing with the RAM preload contents causing some drama during synthesis. I fixed it by putting the full path to the memory data file in the $readmemh statement. Earlier I thought I'd once fixed it with the tool's memory file path setting but it came back to haunt me so I gave up and just hardcoded the memory file path in the hubmem.h file, it worked ok then - I might have also renamed it too guessing it didn't like the spin filename extension. That is likely why you are having those problems with Synplify and its build won't boot without the proper memory contents.
The dynamic clock select (DCSC) block needs two SEL inputs. If SEL0 is high and SEL1 is low then CLK0 is selected, otherwise if SEL1 is high and SEL0 is low then CLK1 is selected. From memory, (I can't get to my code right now) I just created two signals for this based on the 3 LSBs of the clock mode register, something like this..
Yes I think there might be a discrepancy in the documention with respect to that, just hunt through the library file source to see the correct names. Unfortunately my PC is not available for me to confirm the precise syntax for you right now. I had also selected the "POS" attribute for DSCMODE making it rising edge triggered - that seemed to work ok, though I didn't ever hammer the glitchless transition to try it out as it only happens once after boot anyway.
Like you I was also thinking about the internal oscillator possibly being used for RCfast (or even RCslow). Maybe that would help free the PLLs further. The USB clock may be possible to derive in other ways - right now I'm happy enough to just use 96MHz as I know I can then get USB to work with my existing simple mod I made to the already working USB host code that SaucySoliton optimized for 80MHz without further development. I already have it working out with keyboards and mice that way on a DE0-nano and so there should not need to be further work done. For the 480MHz VCO there is a dependency however in obtaining some source frequency that is a multiple of either 10MHz, 12MHz or 15MHz and that then puts some small burden onto the first PLL to cascade an output at that rate into the second PLL. However for the commonly used video resolutions I think it is okay and there should always be a way. Eg:
HDTV 480p/576p: Needs HDMI clocks of 27&135 MHz (use 675MHz VCO), can also supply a 15MHz source multiple for PLL2
HDTV 720p/1080i : Needs HDMI clocks of 75&375MHz (use 750MHz VCO), can also supply a 15MHz source multiple for PLL2
VGA 640x480@60Hz : Needs HDMI clocks of 25&125MHz (use 750MHz VCO), can also supply a 15MHz source multiple for PLL2
SVGA 800x600@60Hz: Needs HDMI clocks of 40&200MHz (use 600MHz VCO), can also supply a 10/12/15MHz source multiple for PLL2
XGA 1024x768@60Hz: Needs HDMI clocks of 65&325MHz (use 650MHz VCO), can also supply a 10MHz source multiple for PLL2
Basically the best way to do it will just depend on what video modes are required/possible.
If 15MHz as an output is too fast for RCfast then PLL2 in my approach above could output 10MHz or 12MHz instead. I liked the idea of a 15MHz clock as it also potentially gives the prop access to another independent frequency for other purposes later. I thought the delays in Chip's booter were written to cope with RC process variations up to 20MHz but I never tried that high. Maybe there are other sensitivities in the download timing from the PC side too...?
@octetta, not sure if there will be further FleaFPGA Ohms available as the Indiegogo has now finished, that is something for Valentin to say, but in the very short term you'd probably be better with another board until this one has stabilised if you are waiting for a bit file to use. The De0-nano is a system that gets commonly used by P1V fans too, though that newer MAX10 based board looks nice and probably has way more value. Even if you don't synthesize it all from the P1V source you could still need to use some parts of the tools to actually load/flash the bit file into the FPGA (or use some other JTAG methods). Today it is tricky if not impossible to just buy a pre-purchased board with some P1+ already available and all ready to go, though perhaps one day your wish will be granted...
In the P1 forum there's a thread about the P1V with the DE10-lite.
This looks like a fairly low cost way to do a full P1V...
Thanks for the thread to follow Rayman.
Just to be clear, for the current P2 design there are binaries that target cyclone IV or cyclone V FPGAs, such as the DE0-Nano. If you want to be able to run both P2 and P1V's, something like the DE0-Nano is a good option to start with.
If you're happy with P1V (and don't need P2 to play with) then there's a really wide choice, because the verilog can be adapted to whatever target you might need.
Thought I better add this, since we're in the P2 forum (though discussing P1V's). To my knowledge Chip hasn't done any compiles for Max10 nor cyclone 10, yet.
For someone like me who is FPGA IQ impaired, would it be possible to buy one of these gizmos and just load the device without synthesis/etc for Prop enhanced development?
I'm hungry for a Prop+ device but don't have time or inclination to to FGPA-specific development or $$$ for the high-end dev kits normally presented here.
I know it's a bit lazy for me to ask this, so please don't judge me too harshly.
Also at first glance, it wasn't clear if it's still possible to purchase the Flea device...
The FleaOhm board can be programmed with premade bitfiles very easy. You just need a little EXE to load the bitfile over bitbanged JTAG. This exe is only 95 kByte in size! No need to download Gigabytes of data for the FPGA synthesis tool.
I think many of the purchasers of this board just load the Amiga emulation bitfile and don't want to do FPGA developement.
There will be a few ready to use P1V bitfile variants soon. I hope for some standardization.
The advantage of the ECP5 FPGA on the Ohm board is that it's in a pricerange that allows to use it as a real P1 replacement, if you need the additional features in a product.
DE10 lite, DE0 Nano and many other boards have expensive FPGAs on board and are only cheap because they are sponsored by the FPGA manufactors.
Great news on your progress Andy - once my PC is available again I want to try some 96MHz PLL clock synthesis and USB.
Have to agree with you that this board is really nice for people who want something without the full toolset, but just not sure if/when newcomers like octetta will be able to get their hands on one if not already purchased, unless Valentin has spares left over or plans another production run soon. But it's worth octetta enquiring with him directly via PM I guess if Valentin doesn't read this. I let him know we've been discussing his board here, sounds like he's still busy with his workload.
I also hope for some standardisation and the FleaFPGA Ohm board IO pinouts are rather interesting. As you'd already know there's also a handful more IO than there are 32 bits in a regular P1V IO port so some creativity is required to gain full use of everything available on this board.
Was wondering about a good IO mapping and the pin numbering on its Raspi compatible header. Some thoughts that could affect choices...
1) Some Raspi HATs might like to be plugged in and used by people. I wonder if it may also be useful to access the dedicated I2C PROM parts on HATs perhaps via those secondary I2C pins on the header. Never done that myself so not sure what it would be required for. Maybe they are not important enough to be mapped out to GPIO on a P1V and port bits can be saved.
2) The FleaFPGA Ohm HW supports a special ADC mode on four of the Raspi header pins, it would be nice to have a way to access it. A suitable ADC peripheral could be developed and possibly HUB controlled via an extended HUBOP. I did a shared I2S peripheral that way previously for P1V. When in ADC mode you wouldn't have to have IO control of those pins, and more port bits can be saved.
3) For the on-board LED - I just used a copy of the Tx pin state for this but some people might prefer direct control of it, independent of the TX pin.
4) Make use of on board USB FTDI serial for P30/P31 which is obviously very convenient over needing a prop plug. In other cases people might want to power externally via the header pins and use an external prop plug on some header pins. I like both possibilities, maybe duplicate TX to both locations and logically AND the RX pin so you get both outcomes.
5) We could use the independent pin input to reset the prop logic (the most obvious use for it), this input could be coupled with RTS timeout circuit.
6) The secondary USB port is currently unused and P1 USB host driver only supports a single USB host (maybe that SW could be extended eventually). Also the USB port pullup/pulldown pin is shared over both ports so you can't ever do a mix of both PS/2 and USB ports, it's one type or the other. I was wondering if one day some minimalist/non-standard USB hub implementation could be added to the FPGA where data is replicated out both USB ports and only the selected device (keyboard or mouse) responds. That way maybe we could get a poor man's USB hub and be able to plug in two devices and share the one instance. Be a lot easier to use a proper external USB hub of course if the SW supports it, but could be nice to just plug in two USB devices without additional HW needed if that is possible. It's a way out idea though - I'm happy to admit that.
7) A P1V portB could be implemented for the extra IO required but introduces potential compatibility issues with existing objects. Ok for people who are happy to patch their driver code but can break things otherwise (eg. if you put the SD card on portB you'd be in for a world of pain in patching objects). I was thinking it could be handy to have a way to enable portB in SW after a COG boots, so legacy PASM driver code that uses dirb as an extra storage register is unaffected and won't short out anything by mistake. Basically we might want some type of control pin for enabling dirb outputs, some special HUBOP to enable it perhaps. Newer code written to use portB would have to enable this explicitly. Unfortunately it gets ugly both ways.
8. USB host code requires its pins mapped to lower 9 bits of a port (uses MOVS with constants I think), and USB code uses another IO pin for internal timing use as well.
9) If not used for PS/2 ports, the second currently unused USB port could possibly be used for a stereo PWM audio output (with a custom cable adapter that just includes a couple of capacitors for the filter - the series resistor is already on board :-) . This PWM output could either be some shared peripheral in the HUB or a duplicate of some given IO pins - I was thinking that approach avoids building a separate board with components for getting analog audio out and keeps things minimal.
10) Definitely wamt a way to map some P1V IO pins or a dedicated peripheral to the SPI PROM pins for access of P1V flash data which is certainly needed at booter time if you don't intend to use an external I2C ROM, and maybe could be handy to have still access it with actual P1V user code as well. This potentially chews up another 4 pins. Possibly a portB candidate.
11) Be nice for Raspi GPIO numbers to line up with P1V port bit numbers perhaps to make it easy for people to use them, though the SD card might need to share four of them too. Duplicate some SPI output pins with header pins perhaps?
I used the onboard FTDI for serial programming from begin, I have never connected a PropPlug to the FleaOhm so far.
It's nice to have a single USB cable to power the board, write the FPGA configuration, load the P1V Spin program and communicate with the application you loaded.
With the pinout I've posted I tried to follow the Demoboard/HumanInterfaceBoard standard for SDcard and PS/2-keyboard, I also put P28/29 at the SCL/SDA pins of the RasPI header. I left out the ID EEPROM pins of the Hats.
There are not much more external accessible pins on the Ohm board, maybe additional 5..7 for a PortB.
My idea was also to add some HUB peripherals to the Propeller concept. I think it makes sense to add dedicated SPI hardware for SDcard and Flash access. They both need a full cog on P1 to provide a medium speed SPI, if you do the SPI in Verilog, Flash can easy go to 40 MHz and SD to 20 MHz bitrates, takes only a few hundred LUTs to free 2 cogs and some portpins. Same goes for SDRAM and HDMI Video, and maybe also the low level access of the USB host driver.
You can still do SPI, UART, I2C in software on a cog for modules or chips connected via portpins.
Compatibelity to existing objects, like FSRW, can be done by replacing objects with the same interface methodes.
Congratulations to both of you for successfully porting P1V to my humble little board - well done!
Previously (before things got crazy with Indiegogo and obliterating all of my free time lol), I had butted my head up against a wall with Synplify Pro Would you believe my experience with LSE vs Synplify had previously been the complete opposite to yours up until this point? ie. namely LSE in past projects not working with anything I attempted to port to the ECP5 FPGA. Now I notice with LSE (when I switched over to it after giving up on Synplify...) all of a sudden I had signs of life in the shape of P1V attempting to read from an external i2c ROM! Alas had to leave it at that because my detailed understanding of the prop was (and still is) rather minimal..
Regarding future Ohm shipments - can't look at that until after Chinese holidays are over at the earliest - if I have time.
Has anyone tried this with the Gnarly Grey FPGA board that has a iCE40UP5K? FYI, he seems to have an update to his board that includes an on-board FT232H for programming the FPGA. The new one is $15.99 though.
Has anyone tried this with the Gnarly Grey FPGA board that has a iCE40UP5K? FYI, he seems to have an update to his board that includes an on-board FT232H for programming the FPGA. The new one is $15.99 though.
Haven't tried no, but with only 5k LUTs the iCE40UP5K is obviously much smaller. Maybe it could still do a 2 COG system perhaps? We can get 3 COGs (or perhaps 4 if they're heavily stripped down) into an 8k LE MAX10.
Could be worth downloading the Lattice tools and you giving it a try if you've already got the board to see if it fits and is close to meeting timing. While its block RAM is only 15kB it does appear to have 128kB of extra SRAM which may let you hold some interesting sized LMM programs internally if it could be mapped into the hub space for example.
Has anyone tried this with the Gnarly Grey FPGA board that has a iCE40UP5K? FYI, he seems to have an update to his board that includes an on-board FT232H for programming the FPGA. The new one is $15.99 though.
Haven't tried no, but with only 5k LUTs the iCE40UP5K is obviously much smaller. Maybe it could still do a 2 COG system perhaps? We can get 3 COGs (or perhaps 4 if they're heavily stripped down) into an 8k LE MAX10.
Could be worth downloading the Lattice tools and you giving it a try if you've already got the board to see if it fits and is close to meeting timing. While its block RAM is only 15kB it does appear to have 128kB of extra SRAM which may let you hold some interesting sized LMM programs internally if it could be mapped into the hub space for example.
There are none checked in anywhere yet to my knowledge as it is still early days being developed. I just started with the Pipistrello codebase (can be found here: saanlima.com/forum/download/file.php?id=23) and made some local mods for enabling raw clocking in top.v and patching the full file path into the $readmemh. I don't have access to my files to make anything available for you right now as my PC is non-functional until I sort out its power supply. :frown:
As well as clocking changes you would also need to do some further work to customize the IO pinouts to your board and try to map the hub RAM to the resources in the target FPGA given it only has 15kB of Block RAM. It's not just a drop in there is some extra work required.
Andy,
What is the boot time like for the ECP5 fpga?
I think you are right about it being the lowest cost full P1V option...
The Lattice MachXO3 is also low cost, but probably can't do the full P1V.
But, it does have the onboard memory that gives it instant-on...
The config size is 591'938 bytes. Standard SPI clock is 2.4 MHz this makes 1.97 s to load a configuration at powerup.
But you can speed this up with custom settings. The SPI clock can go up to 62 MHz and Dual and Quad Read modes are possible. The FleaOhm can not do Quad mode, so fastest config is with FastDualRead and 62 MHz. This results in 39 ms if I have calculated it correct.
I like the smaller Lattice FPGAs like MachXO2/3 and ICE40, but they are not suitable for P1V, not enough RAM and LUTs, and in case of ICE40 Ultra(Plus) not enough speed.
Is it a desktop or laptop Roger? If its a laptop I've got the perfect solution...
Desktop - just need to add some more load to the supply I believe as I have this ultra quiet Antec (and now antique) HE430W supply in a quiet case which apparently is prone to this minimum load issue. A recently replaced GFX card and SSD now draw a lot less than this power supply likes on its 12V rails at startup compared to the original system I put together way back when. I had fixed it for some time by adding some funky cold cathode lights I had lying around drawing ~ 0.6A @12V from a fan header on the motherboard which let it boot for a few months but that no longer appears to work and I now have the original symptoms again where it doesn't startup as of a few of days ago. Hope I didn't burn out any PCB tracks! Will have to just pull things apart and try some experiments, maybe adding a 15ohm 10W resistor across 12V ATX wiring should help load it. Can't bring myself to buy a new and noisy supply or add extra fans etc, this old workhorse system is just so perfectly silent and I'm so used to that. But if I fail I might finally get an incentive to just buy another quiet/small system for FPGA and circuit dev.
I recall I once built a small MOSFET timing circuit that loads the supply at powerup and then disconnects itself and gave it to a mate with the same system with problems, will have to see if I can get it back now or go build it again.
remember those programmable dummy loads you found on aliexpress? Perhaps they'd let you work out exactly what min load you need, then you can replace with a resistor
no fleafpga in the mailbox this morning. fingers crossed for tomorrow
The pricing on the 10m50 is all over the place, while the 10m50daf484c8g is $135 and needs multiple regulators, the 10m08sae144c8g is $66 and needs a single supply rail.
So here's one of the catches... the eqfp packs only have 1 pll no matter what the logic size. I think the power efficiency isn't quite as good in the single rail versions either.
Yes the ECP5 chips seem really good value, especially given they're achieving 80 MHz on the slow speed grade...
...
Yes the ECP5 chips seem really good value, especially given they're achieving 80 MHz on the slow speed grade...
Timing analyzer says only about 50 MHz for cog-clock and 120MHz for pll-clock but it works well with 80 and 160 MHz.
These ECP5 devices are the high end FPGAs of Lattice with up to 5 GHz SERDES, so they must be made in a fast process technology. These timing results must be very conservative, so I wanted to see how high I can go with the frequencies.
The result was really surprising: I can run the good old graphics demo with 150 MHz cog-clock and 300 MHz pll-clock !!!
At 162 / 325 MHz it gets flaky, and at 175 / 350 MHz it fails (the video generator still generates some pixels and a sync signal).
I think this is on par with what Cyclones can do.
I set it then to 125 / 250 MHz for a few more tests. At this frequency also FSRW with the fastest tricky SPI low level driver worked.
BTW: I put back the rom-font, and the rom-tables into the higher 32kB RAM. Without them the video tests were no joy (pipistrello version only had the booter/runner in top 4kB). You always can overwrite the top RAM with code/data if font and tables are not needed.
hey that's really impressive, Andy. Also makes me wonder whether the hdmi data could be waitvid generated . And this is on the lowest speed grade device too isn't it. Although there are other ways to do hdmi
From what I remember on OzPropDev's tests the Max10's were able to get to around 135 MHz, Cyclones were slightly lower (perhaps 115 or 120?)
Still no joy for us in AU on the fleaohm boards. They landed in Sydney on Tuesday, but unfortunately our mail system in AU has cut some costs and isn't what it used to be.
hey that's really impressive, Andy. Also makes me wonder whether the hdmi data could be waitvid generated .
I was thinking about this recently. I think it could be generated like that if there was a way to notify the HDMI port of some "DisplayEnable" flag indicating the demarcation between active/blank pixels on each line. If there was a way to pass this state in it could be possible to pass 6 bits of colour output along with 2 bits of sync, like many VGA drivers already do, into an HDMI input port from Waitvid and it would also be a resolution independent method. Just using h/vsync alone is not enough unless the HDMI HW code already has prior knowledge of number of active pixels and their offset from the syncs. Perhaps a simple(?) hack could be made to waitvid that could be used to latch an extra bit to indicate it. e.g. something like this:
WAITVID colours, pixels (behaves as normal, 8 bits of colour include H/V)
WAITVID colours, pixels WC (indicates a blank region of the line, this could potentially not write the C bit too to avoid trashing C).
Of course the existing drivers would need to be modified slightly to enable this. And the actual video timing chosen still has to work with the monitor. But it might be a rather quick way to get things to work with HDMI.
Another possibly simpler way that doesn't need WAITVID mods might be to split the 8 bits of data into two types (active or blanking) using a new format. The data format is 1 flag bit, and 7 data bits...
Active pixel format:
MSB = 0 : spare bit (or perhaps used for hi/lo intensity selection) : 6 bits of RGB colour
Blanked pixel format:
MSB = 1 : 5 spare bits : H sync bit : V sync bit
It would still need some existing video driver mods to allow it work.
Also for both these ideas, a pixel clock and a 5x (or 10x) clock are still going to be required for the HDMI HW to do the final encoding. There needs to be a way to feed a clock into a PLL to multiply it up unless the video generator can go that high internally. It might be able to generate 125MHz and use DDR IO for VGA @ 250Mbps over HDMI lanes, but jitter could be an issue. Probably better to select a clock already at the correct rate.
Comments
Hey did you get some valid timing constraints setup? I have been trying to get that part sorted myself and there appears to be a myriad of various constraint format options/legacy versions SDC vs FDC etc. So I think it often doesn't meet timing without this file being present and correct.
I've been using Synplify (in Linux) and while yes I do see warnings they mainly appeared to be forward declaration types etc and I did get it to map okay. Funny you mentioned LSE as being better as I had compiler issues with LSE but that was with a different codebase which probably still included some System Verilog bits and pieces that upset things, I might have to retry with the newer P1V code that I'm currently using that Magnus had cleaned up for Xilinx use.
Are you sure that the board needs a resistor mod for RTS? A while back I had asked Valentin to add it and his updated schematic shows it already connected via a 10k resistor to P89B pin as well as to the JTAG interface (it does double duty for both purposes). Hopefully this change actually made it into the final board rev so no-one should have to rework the board, at least that was my intent in requesting it originally. I would have preferred DTR but I think he mentioned that was not available on the FTDI part he uses, but having RTS is better than nothing at all.
In some experiments I found that in my case the clock switching logic worked best for meeting timing if you only switch to 80MHz from a lower speed bootup clock (eg. 12.5MHz) using the glitchless DCSC block in the middle of the FPGA and just leave the higher speed 160MHz signal alone (like you did). Clocks seem best driven directly from PLL outputs not via the original P1V clock divider circuit which has problems with timing. Maybe having valid timing constraints could fix that, not sure...
I am considering using the following PLL setup to allow future HDTV (720p) via HDMI and a USB host in P1V software.
First PLL - input 25MHz from external OSC (VCO set to 750MHz)
output 1 - 375 MHz (5x pixel clock for HDMI's 10x output via DDR IO)
output 2 - 75 MHz (HDTV pixel clock, close to official 74.25MHz, Valentin mentioned it work for his setups but YMMV)
output 3 - 12.5 MHz for slow prop clock
output 4 - spare (this can be 750MHz divided by any integer from 2-128)
Second PLL - input 75MHz clock from PLL1 output (VCO set to 480MHz), this PLL input is also pre-divided to 15MHz
output 1 - 160 MHz (fakePLL clock for P1V)
output 2 - 96 MHz (for USB clock to video generator via a P1V counter mod I already made for this previously)
output 3 - 80 MHz (main P1V clock)
output 4 - 30 or 60MHz (I believe this would be needed to allow feedback divider to use a multiple of 15MHz)
So far haven't got it quite nailed down and working fully but I hope this clocking should be possible.
There are some other options for the PLL output for HDMI clocks which could be 27MHz and 135MHz for 480p or 65MHz and 325MHz for 1024x768 resolutions, or possibly 25MHz and 125MHz for somewhat simpler DVI at 640x480. The ECP5 PLL settings are not dynamic so the desired resolution needs to be fixed in each bit file. Having 27MHz could be quite good for doing digital audio over HDMI.
As you say reusing flash after the FPGA switches to user mode should be possible to replace the i2c PROM with a custom booter which is doable - we already did this ourselves for MAX10 internal flash use too. There is a small piece of HW logic required though as you will need to use a custom Lattice component (USERMCLK) to allow the CCLK output to be driven by user logic to control the SPI ROM after FPGA config completes (normally this pin tri-states and is not accessible as regular IO). Lattice config documentation has more details there. I was just reading about that bit yesterday
Cheers,
Roger.
First PLL - input 25MHz from external OSC (VCO set to 750MHz)
output 1 - 375 MHz (5x pixel clock for 720p)
output 2 - 75 MHz (720p HDTV pixel clock, close to official 74.25MHz)
output 3 - 125 MHz (5x pixel clock for VGA output over HDMI)
output 4 - 25 MHz (for VGA pixel clock)
Second PLL - input 75MHz clock from PLL1 output (VCO set to 480MHz), this PLL input is also pre-divided to 15MHz
output 1 - 160 MHz (fakePLL clock for P1V)
output 2 - 96 MHz (for USB clock)
output 3 - 80 MHz (fast P1V clock)
output 4 - 15MHz (slow P1V clock)
I see now the resistor from TDI to P89B in the schematic. It's hard to find in that part of the schematic especially if you have no clue that it could exist
So we don't need to make any hardware modification - that's really great. Thank's for bringig that to Valentin.
I've not done serious timing analysis. I just looked at the max. frequency values that LSE gives after a synthesis. The clk_cog value does not reach 80 MHz, but I get quite different values depending on how I generate the clock. I first used the internal oscillator with some dividers for all clocks and got higher values than with PLL. In practice it seems to work at 80 MHz, but I need to do more tests, especially with counter-PLL and video.
The rcfast clock is somewhat critical for a seamless download from PropTool. I can only download reliable, if the clock is around 12..13 MHz. But I think we can use the internal oscillator for this clock if it simplifies the PLL usage for the other clocks.
I have not thought about HDMI and USB clocks so far. Why not reserve one PLL for HDMI clock exclusively. USB should be doable with a NCO based receiver and transmitter in Verilog (like on P2).
I've tried to use the DCSC block for glitchless clock switching, but always got errors for unknown parameter names. The description in the appnote seems not to match the IP definition in Diamond. Maybe you can say me how the SEL input is called now.
Normally Synplify is the better synthesis tool (more standard) but in this case it produces no working bitfile. It has to do with the RAM generation, it says that the RAM outputs have no load - makes no sense. To my surprise LSE worked immediately and LUT usage is mostly lower with LSE.
Andy
I'm hungry for a Prop+ device but don't have time or inclination to to FGPA-specific development or $$$ for the high-end dev kits normally presented here.
I know it's a bit lazy for me to ask this, so please don't judge me too harshly.
Also at first glance, it wasn't clear if it's still possible to purchase the Flea device...
Seems like FPGA should be able to handle it...
This looks like a fairly low cost way to do a full P1V...
Thanks for the thread to follow Rayman.
So I had the exact same problems you are seeing with the RAM preload contents causing some drama during synthesis. I fixed it by putting the full path to the memory data file in the $readmemh statement. Earlier I thought I'd once fixed it with the tool's memory file path setting but it came back to haunt me so I gave up and just hardcoded the memory file path in the hubmem.h file, it worked ok then - I might have also renamed it too guessing it didn't like the spin filename extension. That is likely why you are having those problems with Synplify and its build won't boot without the proper memory contents.
The dynamic clock select (DCSC) block needs two SEL inputs. If SEL0 is high and SEL1 is low then CLK0 is selected, otherwise if SEL1 is high and SEL0 is low then CLK1 is selected. From memory, (I can't get to my code right now) I just created two signals for this based on the 3 LSBs of the clock mode register, something like this..
wire sel1 = (clkmode != 3'b0);
wire sel0 = (clkmode == 3'b0);
Yes I think there might be a discrepancy in the documention with respect to that, just hunt through the library file source to see the correct names. Unfortunately my PC is not available for me to confirm the precise syntax for you right now. I had also selected the "POS" attribute for DSCMODE making it rising edge triggered - that seemed to work ok, though I didn't ever hammer the glitchless transition to try it out as it only happens once after boot anyway.
Like you I was also thinking about the internal oscillator possibly being used for RCfast (or even RCslow). Maybe that would help free the PLLs further. The USB clock may be possible to derive in other ways - right now I'm happy enough to just use 96MHz as I know I can then get USB to work with my existing simple mod I made to the already working USB host code that SaucySoliton optimized for 80MHz without further development. I already have it working out with keyboards and mice that way on a DE0-nano and so there should not need to be further work done. For the 480MHz VCO there is a dependency however in obtaining some source frequency that is a multiple of either 10MHz, 12MHz or 15MHz and that then puts some small burden onto the first PLL to cascade an output at that rate into the second PLL. However for the commonly used video resolutions I think it is okay and there should always be a way. Eg:
HDTV 480p/576p: Needs HDMI clocks of 27&135 MHz (use 675MHz VCO), can also supply a 15MHz source multiple for PLL2
HDTV 720p/1080i : Needs HDMI clocks of 75&375MHz (use 750MHz VCO), can also supply a 15MHz source multiple for PLL2
VGA 640x480@60Hz : Needs HDMI clocks of 25&125MHz (use 750MHz VCO), can also supply a 15MHz source multiple for PLL2
SVGA 800x600@60Hz: Needs HDMI clocks of 40&200MHz (use 600MHz VCO), can also supply a 10/12/15MHz source multiple for PLL2
XGA 1024x768@60Hz: Needs HDMI clocks of 65&325MHz (use 650MHz VCO), can also supply a 10MHz source multiple for PLL2
Basically the best way to do it will just depend on what video modes are required/possible.
If 15MHz as an output is too fast for RCfast then PLL2 in my approach above could output 10MHz or 12MHz instead. I liked the idea of a 15MHz clock as it also potentially gives the prop access to another independent frequency for other purposes later. I thought the delays in Chip's booter were written to cope with RC process variations up to 20MHz but I never tried that high. Maybe there are other sensitivities in the download timing from the PC side too...?
@octetta, not sure if there will be further FleaFPGA Ohms available as the Indiegogo has now finished, that is something for Valentin to say, but in the very short term you'd probably be better with another board until this one has stabilised if you are waiting for a bit file to use. The De0-nano is a system that gets commonly used by P1V fans too, though that newer MAX10 based board looks nice and probably has way more value. Even if you don't synthesize it all from the P1V source you could still need to use some parts of the tools to actually load/flash the bit file into the FPGA (or use some other JTAG methods). Today it is tricky if not impossible to just buy a pre-purchased board with some P1+ already available and all ready to go, though perhaps one day your wish will be granted...
Roger.
Just to be clear, for the current P2 design there are binaries that target cyclone IV or cyclone V FPGAs, such as the DE0-Nano. If you want to be able to run both P2 and P1V's, something like the DE0-Nano is a good option to start with.
If you're happy with P1V (and don't need P2 to play with) then there's a really wide choice, because the verilog can be adapted to whatever target you might need.
Thought I better add this, since we're in the P2 forum (though discussing P1V's). To my knowledge Chip hasn't done any compiles for Max10 nor cyclone 10, yet.
The FleaOhm board can be programmed with premade bitfiles very easy. You just need a little EXE to load the bitfile over bitbanged JTAG. This exe is only 95 kByte in size! No need to download Gigabytes of data for the FPGA synthesis tool.
I think many of the purchasers of this board just load the Amiga emulation bitfile and don't want to do FPGA developement.
There will be a few ready to use P1V bitfile variants soon. I hope for some standardization.
The advantage of the ECP5 FPGA on the Ohm board is that it's in a pricerange that allows to use it as a real P1 replacement, if you need the additional features in a product.
DE10 lite, DE0 Nano and many other boards have expensive FPGAs on board and are only cheap because they are sponsored by the FPGA manufactors.
Andy
I got the DCSC (dynamic clock select) to work, thank's. Also the reset over the internal RTS connection works well.
I can output NTSC video at 80 MHz CPU clock and 160 MHz PLL emulation clock, without problems. I have not yet tried VGA.
It looks like the ECP5 is capable of a full P1V.
I will now wait with any P1V improvements until all have got their FleaOhm boards, so that some cooperation is possible.
Andy
Have to agree with you that this board is really nice for people who want something without the full toolset, but just not sure if/when newcomers like octetta will be able to get their hands on one if not already purchased, unless Valentin has spares left over or plans another production run soon. But it's worth octetta enquiring with him directly via PM I guess if Valentin doesn't read this. I let him know we've been discussing his board here, sounds like he's still busy with his workload.
I also hope for some standardisation and the FleaFPGA Ohm board IO pinouts are rather interesting. As you'd already know there's also a handful more IO than there are 32 bits in a regular P1V IO port so some creativity is required to gain full use of everything available on this board.
Was wondering about a good IO mapping and the pin numbering on its Raspi compatible header. Some thoughts that could affect choices...
1) Some Raspi HATs might like to be plugged in and used by people. I wonder if it may also be useful to access the dedicated I2C PROM parts on HATs perhaps via those secondary I2C pins on the header. Never done that myself so not sure what it would be required for. Maybe they are not important enough to be mapped out to GPIO on a P1V and port bits can be saved.
2) The FleaFPGA Ohm HW supports a special ADC mode on four of the Raspi header pins, it would be nice to have a way to access it. A suitable ADC peripheral could be developed and possibly HUB controlled via an extended HUBOP. I did a shared I2S peripheral that way previously for P1V. When in ADC mode you wouldn't have to have IO control of those pins, and more port bits can be saved.
3) For the on-board LED - I just used a copy of the Tx pin state for this but some people might prefer direct control of it, independent of the TX pin.
4) Make use of on board USB FTDI serial for P30/P31 which is obviously very convenient over needing a prop plug. In other cases people might want to power externally via the header pins and use an external prop plug on some header pins. I like both possibilities, maybe duplicate TX to both locations and logically AND the RX pin so you get both outcomes.
5) We could use the independent pin input to reset the prop logic (the most obvious use for it), this input could be coupled with RTS timeout circuit.
6) The secondary USB port is currently unused and P1 USB host driver only supports a single USB host (maybe that SW could be extended eventually). Also the USB port pullup/pulldown pin is shared over both ports so you can't ever do a mix of both PS/2 and USB ports, it's one type or the other. I was wondering if one day some minimalist/non-standard USB hub implementation could be added to the FPGA where data is replicated out both USB ports and only the selected device (keyboard or mouse) responds. That way maybe we could get a poor man's USB hub and be able to plug in two devices and share the one instance. Be a lot easier to use a proper external USB hub of course if the SW supports it, but could be nice to just plug in two USB devices without additional HW needed if that is possible. It's a way out idea though - I'm happy to admit that.
7) A P1V portB could be implemented for the extra IO required but introduces potential compatibility issues with existing objects. Ok for people who are happy to patch their driver code but can break things otherwise (eg. if you put the SD card on portB you'd be in for a world of pain in patching objects). I was thinking it could be handy to have a way to enable portB in SW after a COG boots, so legacy PASM driver code that uses dirb as an extra storage register is unaffected and won't short out anything by mistake. Basically we might want some type of control pin for enabling dirb outputs, some special HUBOP to enable it perhaps. Newer code written to use portB would have to enable this explicitly. Unfortunately it gets ugly both ways.
8. USB host code requires its pins mapped to lower 9 bits of a port (uses MOVS with constants I think), and USB code uses another IO pin for internal timing use as well.
9) If not used for PS/2 ports, the second currently unused USB port could possibly be used for a stereo PWM audio output (with a custom cable adapter that just includes a couple of capacitors for the filter - the series resistor is already on board :-) . This PWM output could either be some shared peripheral in the HUB or a duplicate of some given IO pins - I was thinking that approach avoids building a separate board with components for getting analog audio out and keeps things minimal.
10) Definitely wamt a way to map some P1V IO pins or a dedicated peripheral to the SPI PROM pins for access of P1V flash data which is certainly needed at booter time if you don't intend to use an external I2C ROM, and maybe could be handy to have still access it with actual P1V user code as well. This potentially chews up another 4 pins. Possibly a portB candidate.
11) Be nice for Raspi GPIO numbers to line up with P1V port bit numbers perhaps to make it easy for people to use them, though the SD card might need to share four of them too. Duplicate some SPI output pins with header pins perhaps?
Lot's of possibilities arise...
Roger.
We appreciate the manners, but no real need to wait for us, keep playing while great progress is being made
Might be worth a quick email to Valentin to let him know the good news too
I used the onboard FTDI for serial programming from begin, I have never connected a PropPlug to the FleaOhm so far.
It's nice to have a single USB cable to power the board, write the FPGA configuration, load the P1V Spin program and communicate with the application you loaded.
With the pinout I've posted I tried to follow the Demoboard/HumanInterfaceBoard standard for SDcard and PS/2-keyboard, I also put P28/29 at the SCL/SDA pins of the RasPI header. I left out the ID EEPROM pins of the Hats.
There are not much more external accessible pins on the Ohm board, maybe additional 5..7 for a PortB.
My idea was also to add some HUB peripherals to the Propeller concept. I think it makes sense to add dedicated SPI hardware for SDcard and Flash access. They both need a full cog on P1 to provide a medium speed SPI, if you do the SPI in Verilog, Flash can easy go to 40 MHz and SD to 20 MHz bitrates, takes only a few hundred LUTs to free 2 cogs and some portpins. Same goes for SDRAM and HDMI Video, and maybe also the low level access of the USB host driver.
You can still do SPI, UART, I2C in software on a cog for modules or chips connected via portpins.
Compatibelity to existing objects, like FSRW, can be done by replacing objects with the same interface methodes.
Andy
Congratulations to both of you for successfully porting P1V to my humble little board - well done!
Previously (before things got crazy with Indiegogo and obliterating all of my free time lol), I had butted my head up against a wall with Synplify Pro
Regarding future Ohm shipments - can't look at that until after Chinese holidays are over at the earliest - if I have time.
Regards,
Valentin
What is the boot time like for the ECP5 fpga?
I think you are right about it being the lowest cost full P1V option...
The Lattice MachXO3 is also low cost, but probably can't do the full P1V.
But, it does have the onboard memory that gives it instant-on...
Haven't tried no, but with only 5k LUTs the iCE40UP5K is obviously much smaller. Maybe it could still do a 2 COG system perhaps? We can get 3 COGs (or perhaps 4 if they're heavily stripped down) into an 8k LE MAX10.
Could be worth downloading the Lattice tools and you giving it a try if you've already got the board to see if it fits and is close to meeting timing. While its block RAM is only 15kB it does appear to have 128kB of extra SRAM which may let you hold some interesting sized LMM programs internally if it could be mapped into the hub space for example.
As well as clocking changes you would also need to do some further work to customize the IO pinouts to your board and try to map the hub RAM to the resources in the target FPGA given it only has 15kB of Block RAM. It's not just a drop in there is some extra work required.
The config size is 591'938 bytes. Standard SPI clock is 2.4 MHz this makes 1.97 s to load a configuration at powerup.
But you can speed this up with custom settings. The SPI clock can go up to 62 MHz and Dual and Quad Read modes are possible. The FleaOhm can not do Quad mode, so fastest config is with FastDualRead and 62 MHz. This results in 39 ms if I have calculated it correct.
I like the smaller Lattice FPGAs like MachXO2/3 and ICE40, but they are not suitable for P1V, not enough RAM and LUTs, and in case of ICE40 Ultra(Plus) not enough speed.
Desktop - just need to add some more load to the supply I believe as I have this ultra quiet Antec (and now antique) HE430W supply in a quiet case which apparently is prone to this minimum load issue. A recently replaced GFX card and SSD now draw a lot less than this power supply likes on its 12V rails at startup compared to the original system I put together way back when. I had fixed it for some time by adding some funky cold cathode lights I had lying around drawing ~ 0.6A @12V from a fan header on the motherboard which let it boot for a few months but that no longer appears to work and I now have the original symptoms again where it doesn't startup as of a few of days ago. Hope I didn't burn out any PCB tracks! Will have to just pull things apart and try some experiments, maybe adding a 15ohm 10W resistor across 12V ATX wiring should help load it. Can't bring myself to buy a new and noisy supply or add extra fans etc, this old workhorse system is just so perfectly silent and I'm so used to that. But if I fail I might finally get an incentive to just buy another quiet/small system for FPGA and circuit dev.
I recall I once built a small MOSFET timing circuit that loads the supply at powerup and then disconnects itself and gave it to a mate with the same system with problems, will have to see if I can get it back now or go build it again.
remember those programmable dummy loads you found on aliexpress? Perhaps they'd let you work out exactly what min load you need, then you can replace with a resistor
no fleafpga in the mailbox this morning. fingers crossed for tomorrow
The chip on my DE10-Lite board looks to cost ~$140 and have similar specs to ECP5...
So here's one of the catches... the eqfp packs only have 1 pll no matter what the logic size. I think the power efficiency isn't quite as good in the single rail versions either.
Yes the ECP5 chips seem really good value, especially given they're achieving 80 MHz on the slow speed grade...
Timing analyzer says only about 50 MHz for cog-clock and 120MHz for pll-clock but it works well with 80 and 160 MHz.
These ECP5 devices are the high end FPGAs of Lattice with up to 5 GHz SERDES, so they must be made in a fast process technology. These timing results must be very conservative, so I wanted to see how high I can go with the frequencies.
The result was really surprising: I can run the good old graphics demo with 150 MHz cog-clock and 300 MHz pll-clock !!!
At 162 / 325 MHz it gets flaky, and at 175 / 350 MHz it fails (the video generator still generates some pixels and a sync signal).
I think this is on par with what Cyclones can do.
I set it then to 125 / 250 MHz for a few more tests. At this frequency also FSRW with the fastest tricky SPI low level driver worked.
BTW: I put back the rom-font, and the rom-tables into the higher 32kB RAM. Without them the video tests were no joy (pipistrello version only had the booter/runner in top 4kB). You always can overwrite the top RAM with code/data if font and tables are not needed.
Andy
From what I remember on OzPropDev's tests the Max10's were able to get to around 135 MHz, Cyclones were slightly lower (perhaps 115 or 120?)
Still no joy for us in AU on the fleaohm boards. They landed in Sydney on Tuesday, but unfortunately our mail system in AU has cut some costs and isn't what it used to be.
I was thinking about this recently. I think it could be generated like that if there was a way to notify the HDMI port of some "DisplayEnable" flag indicating the demarcation between active/blank pixels on each line. If there was a way to pass this state in it could be possible to pass 6 bits of colour output along with 2 bits of sync, like many VGA drivers already do, into an HDMI input port from Waitvid and it would also be a resolution independent method. Just using h/vsync alone is not enough unless the HDMI HW code already has prior knowledge of number of active pixels and their offset from the syncs. Perhaps a simple(?) hack could be made to waitvid that could be used to latch an extra bit to indicate it. e.g. something like this:
Of course the existing drivers would need to be modified slightly to enable this. And the actual video timing chosen still has to work with the monitor. But it might be a rather quick way to get things to work with HDMI.
Active pixel format:
MSB = 0 : spare bit (or perhaps used for hi/lo intensity selection) : 6 bits of RGB colour
Blanked pixel format:
MSB = 1 : 5 spare bits : H sync bit : V sync bit
It would still need some existing video driver mods to allow it work.
Also for both these ideas, a pixel clock and a 5x (or 10x) clock are still going to be required for the HDMI HW to do the final encoding. There needs to be a way to feed a clock into a PLL to multiply it up unless the video generator can go that high internally. It might be able to generate 125MHz and use DDR IO for VGA @ 250Mbps over HDMI lanes, but jitter could be an issue. Probably better to select a clock already at the correct rate.