LCD working on FPGA-board!
overclocked
Posts: 80
I'm using the Microblaze Starterkit which includes an older Xilinx Spartan-3E which is beginning to work great with the P1V.
After underclocking the P1V to 120 Mhz PLL (60 MHz CogCLK) most examples started working.
I just managed to get the included LCD working with this OBEX package:
http://obex.parallax.com/object/338
One file was missing (timing.spin) in the package and can be found here:
http://obex.parallax.com/object/446
I rewired the coupling to the LCD to suit the layout of this FPGA-board and changed the clock to suit my underclocked P1V.
Eureka! It works!
After underclocking the P1V to 120 Mhz PLL (60 MHz CogCLK) most examples started working.
I just managed to get the included LCD working with this OBEX package:
http://obex.parallax.com/object/338
One file was missing (timing.spin) in the package and can be found here:
http://obex.parallax.com/object/446
I rewired the coupling to the LCD to suit the layout of this FPGA-board and changed the clock to suit my underclocked P1V.
Eureka! It works!
800 x 600 - 51K
Comments
Would you like to post the verilog zipped for this and the usage so we can compare it to the Cyclone IV please?
Nice! Do you have any plans to add your code to Github?
===Jac
I can fix both zip and Github, but the code is really Magnus Karlsson's so I won't take credit for the actual Xilinx-port although some of the settings to make it work with older devices was my finding. I did lots of work trying to port the code myself. It did compile but didn't boot.
I'll fix the ZIP-file for ya later this week. The question is if the small changes I've done really make it "worth" having a new directory for Spartan-3E?
I'm not an Git-expert but maybe the best way of doing it would be to fork out Magnus's GitHub and start off from that. Then applying my changes ontop of that. But if I create a new directory for the Microblaze Starter Kit, is there any win of doing the fork then?
I've posted the usage elsewhere in other threads, but as a short number: 96-97% slice usage and 100% BRAM usage in the Spartan-3E 1600E.
This includes all features that Magnus added: 64KB HubMem (ROM as RAM init but no Sine/Font for now), 8 COG's, reset helper circuit.
The actual logic only uses about 60-65% of the circuit, but due to BRAM shortage, logic is used to implement all COG-RAM.
I don't have a Xilinx board and I've never even seen the Xilinx software (I have about two weeks more experience with Quartus haha), but maybe it's possible to combine your Spartan-3E build with Magnus' Spartan-6 port so they all build from the same sources? I have no idea if this is possible.
Unfortunately Git doesn't support branching and merging between directories, because it doesn't store history at the file level but at the branch level.
I think the way to go is to do the same thing for the Xilinx targets as what I did for the Altera targets: Fork the repo (probably from Magnus' repo but it doesn't really matter), then create a new directory "Xilinx" containing a copy of Magnus' code, and add your Microblaze.xise and make it refer to the same Verilog files as Magnus. Then, anywhere where there's a difference in the Verilog code between the Microblaze and the Pipistrello, add an `ifdef TARGET_PIPISTRELLO or `ifdef TARGET_MICROBLAZE or whatever. It's probably possible to define macros from the project file so that the Pipistrello compiles to the same binary files as before.
Then you can file a pull request to let Magnus take a look (he's obviously more of a Xilinx and Verilog expert than I am) and he can file a pull request to me etc.
As I mentioned elsewhere, I would REALLY like the default output of all the builds to be as close to the original Propeller chip as possible (exceptions: if it can't run fast enough or if it can run faster than the propeller that's okay, and if the hardware simply can't do it, we'll have to leave obvious features out, such as parts of the hub ROM). New features that change the functionality such as bigger hub memory, different numbers of cogs, different timing etc. should all be turned off by default by using parameters and/or macros. That way a future user who downloads the sources will automatically start out with a standard Propeller that's more or less guaranteed to work the way they expect. To add features, they can add a macro definition or macro override ot their project file (I'm sure the Xilinx software can do something similar) and if certain combinations of features make things break, we can just tell the newbies they're doing it wrong.
I didn't take a close look at the Pipistrello code when Magnus sent me the pull request, so I hope he didn't integrate those features to be enabled by default. If so, we'll need to make some changes.
The source files of the Altera builds are now combined in one directory (in my Altera branch) and if you combine the Pipistrello and Microblaze into one Xilinx directory, that would be great to get towards one code base that's shared by all boards, Altera and Xilinx. If that means that both platforms have to give up conveniences (e.g. if it's necessary to switch to Verilog-2001 instead of SystemVerilog or something like that), I think I'm willing to deal with that, as the price we pay to make it easy to add new features to all platforms at the same time. It may be a far-future thing but if we allow the Xilinx and Altera code bases to drift apart too much, it may soon be too much work to bring them together again.
===Jac
One part that become a contraction is that it would be nice to keep sources original, but Xilinx compatibility demands SystemVerilog=>Verilog-2001 and removing/rewriting TDF-top-level to verilog-2001. After this translation the code is really compatible with both tool-chains so the "original" should be with this syntax for maximum re-usability, for simple/minimal administration and to better comply with standard. The same goes for init-files for ROM.
As long as the "original" files are considered to be Altera-specific file formats, we will never get smooth multi-vendor-support.
I'd agree - Maybe if another term is added like 'Raw' for the starting point, and the 'original' becomes the Portable but Compatible release point. (ie modified RAW for portability, but not for functional )
I would include things like unscramble ROM to be portability, not functional, as the executed code is not changed, just the Logic is simpler and faster and the scramble is removed.
If parameters can define things like COG numbers and Memory sizes, then that is cleanest, and of course they default to Compatible.