Ok I'll get to work on that! Thanks!
EDIT: Actually, I'll wait until rfbrw confirms that a new .mcs file is needed.
EDIT: Actually, I'll wait until rfbrw confirms that a new .mcs file is needed.
I've tried to write out in detail how you get from Verilog code to an MCS file. It's all based on ISE 14.6, I just hope the graphical user interfaces were not changed too much between versions 14.6 and 14.7 and that the FIR compiler 5.0 and FIFO generator 9.3 (or something that's compatible) are still available.
-Download and install ICE; I've always used the free version of ISE 14.6, but you will need 14.7 VM because of the LX150
-Start PlanAhead
-Create a new project:
Project type: RTL Project
Default Part: the exact FPGA type used on your TE0630 module
-Read in the user constraint file:
A. Under Sources, click on the icon with the + sign: Add Sources
B. Click Add or Create Constraints, then Add Files, then browse to the topconstraints.ucf file of the valve DAC version 2.1, click on it and press OK
C. Click on Finish
-Read in the Verilog files:
A. Under Sources, click on the icon with the + sign: Add Sources
B. Click Add or Create Design Sources, then Add Files, then browse to the Verilog files of the valve DAC version 2.1, select all of them and press OK
C. Click on Finish
-Generate the FIFOs and FIR filters:
I hope this part will work out well, that there are no updates made between 14.6 and 14.7 that cause trouble.
A. Click Window, IP Catalog.
B. In the new IP Catalog window, go to Digital Signal Processing, Filters, FIR Compiler 5.0 to generate the FIR filters. It takes a while to launch it. The details of what has to be generated can be found in the file FPGAfiles\FIRandFIFOgeneration.pdf in the files of valve DAC version 1, except that the input word length of filter firdsd6 has to be set to 6 bits rather than 2 bits for valve DAC version 2.1.
C. For the FIFOs, use Memories & Storage Elements, FIFOs, FIFO Generator
-I'm not sure if you have to right-click on the module top in the design sources window to set it as top, or if PlanAhead figures that out automatically - I think the latter.
-Now you have to set some options for synthesis, implementation and bitstream generation, see the file FPGAfiles\PlanAheadoptions_10July2016.txt in the files for valve DAC version 1. The same options were used for version 2.1.
-If I haven't forgotten anything, you can now press Generate Bitstream. You will then get a warning that synthesis and implementation have to be run first, and you have to press Yes to indicate that that is what you want.
-Once the synthesis, implementation and bitstream generation have completed:
A. Choose Launch iMPACT and double-click on Create PROM File. Choose SPI Flash and Configure Single FPGA, arrow to the right, enter the size of the configuration memory on the FPGA module (64 Mbit), arrow to the right, enter the desired file name and press OK (*).
B. You now get a window "Start adding device file to Revision 0", press OK and try to figure out where PlanAhead has hidden the top.bit file. It's usually in the <project name>.runs\impl_1 directory. Select top.bit and open it.
C. When you get a window with the question "Would you like to add another device file to Revision:0 ?", click on No. You then get another window stating that you have finished adding files, close that by clicking OK.
D. Now double-click Generate File in a pane on the main iMPACT window and the mcs file will finally be generated.
PlanAhead always generates lots of warning messages, even when everything is going fine. You might get timing violation warnings after implementation, those need to be taken seriously. The same holds for critical errors.
(*): Maybe I forgot a button Add PROM somewhere in this step.
-Download and install ICE; I've always used the free version of ISE 14.6, but you will need 14.7 VM because of the LX150
-Start PlanAhead
-Create a new project:
Project type: RTL Project
Default Part: the exact FPGA type used on your TE0630 module
-Read in the user constraint file:
A. Under Sources, click on the icon with the + sign: Add Sources
B. Click Add or Create Constraints, then Add Files, then browse to the topconstraints.ucf file of the valve DAC version 2.1, click on it and press OK
C. Click on Finish
-Read in the Verilog files:
A. Under Sources, click on the icon with the + sign: Add Sources
B. Click Add or Create Design Sources, then Add Files, then browse to the Verilog files of the valve DAC version 2.1, select all of them and press OK
C. Click on Finish
-Generate the FIFOs and FIR filters:
I hope this part will work out well, that there are no updates made between 14.6 and 14.7 that cause trouble.
A. Click Window, IP Catalog.
B. In the new IP Catalog window, go to Digital Signal Processing, Filters, FIR Compiler 5.0 to generate the FIR filters. It takes a while to launch it. The details of what has to be generated can be found in the file FPGAfiles\FIRandFIFOgeneration.pdf in the files of valve DAC version 1, except that the input word length of filter firdsd6 has to be set to 6 bits rather than 2 bits for valve DAC version 2.1.
C. For the FIFOs, use Memories & Storage Elements, FIFOs, FIFO Generator
-I'm not sure if you have to right-click on the module top in the design sources window to set it as top, or if PlanAhead figures that out automatically - I think the latter.
-Now you have to set some options for synthesis, implementation and bitstream generation, see the file FPGAfiles\PlanAheadoptions_10July2016.txt in the files for valve DAC version 1. The same options were used for version 2.1.
-If I haven't forgotten anything, you can now press Generate Bitstream. You will then get a warning that synthesis and implementation have to be run first, and you have to press Yes to indicate that that is what you want.
-Once the synthesis, implementation and bitstream generation have completed:
A. Choose Launch iMPACT and double-click on Create PROM File. Choose SPI Flash and Configure Single FPGA, arrow to the right, enter the size of the configuration memory on the FPGA module (64 Mbit), arrow to the right, enter the desired file name and press OK (*).
B. You now get a window "Start adding device file to Revision 0", press OK and try to figure out where PlanAhead has hidden the top.bit file. It's usually in the <project name>.runs\impl_1 directory. Select top.bit and open it.
C. When you get a window with the question "Would you like to add another device file to Revision:0 ?", click on No. You then get another window stating that you have finished adding files, close that by clicking OK.
D. Now double-click Generate File in a pane on the main iMPACT window and the mcs file will finally be generated.
PlanAhead always generates lots of warning messages, even when everything is going fine. You might get timing violation warnings after implementation, those need to be taken seriously. The same holds for critical errors.
(*): Maybe I forgot a button Add PROM somewhere in this step.
Last edited:
Wow, I really appreciate this write up! I did my best to follow along, though the software seems to have changed the menus around a bit. One of the changes is that you don't specify what a source is when you add it (or at least I didn't see that option).
When I used the settings from Planaheadoptions, mapping would not proceed with -global_opt set to speed and -u not checked. I checked -u (Trim Unconnected Signals) so that it would move forward.
There were multiple timing errors, so tomorrow I'll go through and double check everything.
I noticed that the speed grade of the LX150 is 2, while the LX75 is 3. Hopefully that's not an issue. In either case, I eventually got it to spit out a .mcs file, so at least I've got the workflow down for future testing.
When I used the settings from Planaheadoptions, mapping would not proceed with -global_opt set to speed and -u not checked. I checked -u (Trim Unconnected Signals) so that it would move forward.
There were multiple timing errors, so tomorrow I'll go through and double check everything.
I noticed that the speed grade of the LX150 is 2, while the LX75 is 3. Hopefully that's not an issue. In either case, I eventually got it to spit out a .mcs file, so at least I've got the workflow down for future testing.
Attachments
Last edited:
What timing errors do you get? The software tries to iteratively find a placement and routing that meets all timing constraints, so timing violations that occur while it hasn't finished yet are normal. When it reports timing violations when this iterative process is finished, then it is a real problem.
If you only get set-up time violations and no hold violations, and the set-up violations are just a few percent of a clock cycle, then everything will probably still work, but not over the entire temperature range. The highest clock frequency used in the design is 216 MHz, eight times the crystal frequency. Of course it is better not to have any violations at all.
Does it help if you set -opt_level to something slower than fast? I think fast means it doesn't spend too much time trying to optimize it. As far as I remember, I had to set it to spending a lot of time in optimization.
In the UCF file, I put some area constraints that were meant to help it finding a timing-clean solution, but it could be that those only hamper it with a larger FPGA type. You could try commenting out this in topconstraints.ucf:
INST "interpol1" AREA_GROUP="pblock_interpol1";
AREA_GROUP "pblock_interpol1" RANGE=CLOCKREGION_X1Y5:CLOCKREGION_X1Y11;
INST "prefilter1" AREA_GROUP="pblock_prefilter";
AREA_GROUP "pblock_prefilter" RANGE=CLOCKREGION_X1Y1:CLOCKREGION_X1Y4;
If that doesn't help, you could also try commenting out:
NET "interpol1/fir2l/blk00000003/sig000001a5" MAXDELAY = 3.51 ns;
although chances are that commenting that out will only make it worse.
If you only get set-up time violations and no hold violations, and the set-up violations are just a few percent of a clock cycle, then everything will probably still work, but not over the entire temperature range. The highest clock frequency used in the design is 216 MHz, eight times the crystal frequency. Of course it is better not to have any violations at all.
Does it help if you set -opt_level to something slower than fast? I think fast means it doesn't spend too much time trying to optimize it. As far as I remember, I had to set it to spending a lot of time in optimization.
In the UCF file, I put some area constraints that were meant to help it finding a timing-clean solution, but it could be that those only hamper it with a larger FPGA type. You could try commenting out this in topconstraints.ucf:
INST "interpol1" AREA_GROUP="pblock_interpol1";
AREA_GROUP "pblock_interpol1" RANGE=CLOCKREGION_X1Y5:CLOCKREGION_X1Y11;
INST "prefilter1" AREA_GROUP="pblock_prefilter";
AREA_GROUP "pblock_prefilter" RANGE=CLOCKREGION_X1Y1:CLOCKREGION_X1Y4;
If that doesn't help, you could also try commenting out:
NET "interpol1/fir2l/blk00000003/sig000001a5" MAXDELAY = 3.51 ns;
although chances are that commenting that out will only make it worse.
I looked up the difference between the -2 and -3 speed grades in the datasheet, and the delays of the -2 speed grade are typically some 10 % to 15 % higher than for -3, although it depends a lot on what parameter you look at. ISE already had difficulty getting the timing clean with my FPGA, so this extra delay won't help. On the other hand, the lower utilization will give ISE more opportunity to optimize routing delays.
Anyway, please let me know what timing violations you get.
Anyway, please let me know what timing violations you get.
I changed it to take maximum time to do optimization, threw 10 cores at it (not sure how multithreaded it is). I've attached the log folder and some logs I saved manually, which may be redundant. I did not change the .ucf file.
These were the timing errors:
WARNING:Timing:3175 - sdclock does not clock data to dix4192cdin
WARNING:Timing:3225 - Timing constraint COMP "dix4192cdin" OFFSET = OUT 17 ns
AFTER COMP "sdclock" REFERENCE_PIN BEL "dix4192cclk" "FALLING";
ignored during timing analysis
WARNING:Timing:3379 - The REFERENCE_PIN dix4192cclk on constraint COMP "dix4192csn" OFFSET = OUT 15 ns AFTER COMP "sdclock" REFERENCE_PIN
BEL "dix4192cclk" "RISING"; was not included as part of analysis. The REFERENCE_PIN keyword is being ignored.
These were the timing errors:
WARNING:Timing:3175 - sdclock does not clock data to dix4192cdin
WARNING:Timing:3225 - Timing constraint COMP "dix4192cdin" OFFSET = OUT 17 ns
AFTER COMP "sdclock" REFERENCE_PIN BEL "dix4192cclk" "FALLING";
ignored during timing analysis
WARNING:Timing:3379 - The REFERENCE_PIN dix4192cclk on constraint COMP "dix4192csn" OFFSET = OUT 15 ns AFTER COMP "sdclock" REFERENCE_PIN
BEL "dix4192cclk" "RISING"; was not included as part of analysis. The REFERENCE_PIN keyword is being ignored.
The manually saved logs directory appears to be empty.
I need to look into those three warnings you posted, but if you only got those and no set-up and hold time violations, it's not as bad as I feared it might be. If that's true, then basically PlanAhead doesn't "understand" a small part of my timing constraints, but all the really high speed stuff is implemented properly despite the different speed grade.
Edit: I just looked up some comments I put in the .ucf file and apparently PlanAhead also didn't "understand" the first two of these constraints when I generated the .bit and .mcs files for my valve DAC. I didn't manage to figure out how else the constraints should be formulated, but I could see in the timing report that it was met anyway, so I just left it.
I need to look into those three warnings you posted, but if you only got those and no set-up and hold time violations, it's not as bad as I feared it might be. If that's true, then basically PlanAhead doesn't "understand" a small part of my timing constraints, but all the really high speed stuff is implemented properly despite the different speed grade.
Edit: I just looked up some comments I put in the .ucf file and apparently PlanAhead also didn't "understand" the first two of these constraints when I generated the .bit and .mcs files for my valve DAC. I didn't manage to figure out how else the constraints should be formulated, but I could see in the timing report that it was met anyway, so I just left it.
Last edited:
That doesn't look good at all; 68 violations of the set-up times of the firclock domain (which is the 216 MHz domain) with a worst-case slack of -1.226 ns. That is, the worst violation is a 26.48 % violation. Besides, there is something weird going on with the dopdetector hold times.
Could you try it without the area constraints?
Could you try it without the area constraints?
Tried without the area constraints. Took much longer, still spit out some errors. Thinking I should cancel my order and just wait it out till Trenz gets more LX75 in stock.
I'm afraid you are right, this looks like it is not going to work without redesigning for a lower FIR clock frequency. Can you still cancel the order?
The order hasn't been processed yet, so I emailed them to cancel. Shame. When I first ordered the LX75-based one, it said March, then got pushed back to late September. I think in the interim, I will build the DSD-only version.
Confirmed with Trenz that they are having a supplier issue, so September/October is likely the earliest the LX75 will be back in stock. Sucks that the AKM fire derailed the Simple DSD SRC group buy, because that would have been perfect for the DSD-only version. I'll have to become acquainted with HQplayer.
If you want to try without the outlay for HQP in the first instance you might checkout Daphile - IIRC it does PCM to DSD conversion, though not supposed to be as good as HQP - might be sufficient to get you started?
HQP is offered in free trial format. Don't know about the latest version, but for the last version it limited playback to 30minutes at time. One could restart it immediately after it timed out. It was just annoying to use that way for more than some listening tests.
The outlay for HQP isn't just the software cost, you need a pretty meaty computer too! I believe Daphile has much lighter hardware processing requirements.
Also, I think the trial version of HQP stops working at the end of the period though I admit it's a long time since I haven't had a licensed copy.
Also, I think the trial version of HQP stops working at the end of the period though I admit it's a long time since I haven't had a licensed copy.