Author Topic: Learning FPGAs: wrong approach?  (Read 54684 times)

0 Members and 1 Guest are viewing this topic.

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #50 on: June 17, 2017, 12:54:28 am »

Btw, as far as I know. One must account for the outputs and transitions for EVERY state, regardless if those outputs change or not. The "default" case (for outputs) is simply what the signals are going to be upon start up. The "default" case (for transitions) is what the initial state of the state machine is. If you forget to include a state, because the outputs dont change, you will get an error.

Not exactly...

In VHDL you specify default values before the case statement and then you only need to change the value if a particular state needs to do that.

Code: [Select]
process(state, PlotterXIOCmdReq, PlotterXIOCmd, XIOFunction)
begin
SetIntBusy        <= '0';
ClearIntBusy <= '0';
ClearInterrupts <= '0';
case state is
when ACK =>  PlotterXIOCmdAck_i <= '1';
if PlotterXIOCmdReq = '1' then
next_state <= ACK;
else
case XIOFunction is
when XIO_SenseDevice => ClearInterrupts <= PlotterXIOCmd(0);

<clip>


The signal ClearInterrupts is defined to be '0' just before 'case state'.  It will always have a value of '0' unless overridden as it is in case XIOFunction.  Since the value is defined for all states, it will never infer a latch.

This code makes no sense as it was hacked from a much larger FSM.  Nevertheless, it shows the proper technique for declaring default values for the FSM outputs.  The trick is to add new states during development and then add new outputs while not forgetting to declare the default value.  Nothing works if latches are inferred.
« Last Edit: June 17, 2017, 01:07:52 am by rstofer »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #51 on: June 17, 2017, 01:31:10 am »
To each their own I suppose. I don't know what "reasonably sized is" but I have built a 64 bit processor on a DE0 (Cyclone III E3PC16F484C6), using the LCD I spoke of earlier as a peripheral. I even wrote a program for it, the ROM would be read, and would take keyboard input from PS/2 then send the input to the MUX that controls the output to the LCD. Had maybe 500 messages. I found going through them easy. *Shrugs*

This processor was an academic requirement of course and may very well still be considered small. It overclocked to 66 mhz. Base clock was 50 mhz. It was not pipelined, did not have a FPU and could not perform multiplication or division. Very basic processor. The clock multiplier was provided through Altera's megafunction IPs. For the RAM, I made two, one using Altera provided megafunctions, and then describing it in Verilog.

As a rough cut, your device had 15k logic elements (LUTs?) while the MachXO3 we were talking about earlier is less than half that size at 6900 elements.  My Digilent Nexys2 board has 19,512 logic elements so somewhat larger.

The Digilent board costs a lot more than the Lattice board but it has switches, LEDs, 7-Segment display, PS/2 input and VGA output.  It also has parallel flash and RAM on board.  The Lattice board is a LOT cheaper but you're on your own for peripherals.

Still, if are talking about a beginner board, the Lattice board will do a lot of things.  It just won't hold my CPU project...

 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #52 on: June 17, 2017, 04:55:53 am »
I think with these latest posts illustration code already has gone a little too far for what the OP has asked, being someone who has never developed on a FPGA before or even know what the languages are or how they work.
 

Offline westfwTopic starter

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #53 on: June 17, 2017, 05:07:57 am »
(I'm very pleased with the discussion that is being generated here.  A big "thank you" to everyone who is participating!)


Quote
Next step would be to learn one of the HDLs.

Once you've got the beginning of a grip on your chosen HDL, take the 'discrete' design you already made and implement the discrete parts you 'made up' in HDL, interconnect them in HDL, scribble a little HDL test-bed and hit the simulator.

The vendor tools for actual FPGAs can be quite a struggle to set up and get running with - not what you want at the 'hello world' stage. I'd recommend that if you're going Verilog that you grab the open source Icarus iverilog simulator

Wait!  I can write verilog/VHDL and simulate it without picking some vendor tool?  I was thinking that the only compiler/simulators around were in one vendor tool or another...  How does this work, without having the limitations of a particular chip in mind?   I just write my design files, and "later" move it to some vendor chip, tie in pin definitions and such, and see if it fits?  Very interesting!
 
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Learning FPGAs: wrong approach?
« Reply #54 on: June 17, 2017, 05:44:30 am »
Wait!  I can write verilog/VHDL and simulate it without picking some vendor tool?  I was thinking that the only compiler/simulators around were in one vendor tool or another...  How does this work, without having the limitations of a particular chip in mind?   I just write my design files, and "later" move it to some vendor chip, tie in pin definitions and such, and see if it fits?  Very interesting!

Yes - exactly this. The only proviso is that as soon as you use a single vendor-specific doohickey, and don't somehow isolate it from the rest of your design then you have lost that freedom. (much the same as mixing in any OS specific calls in S/W). It is very easy to get seduced by things like "Block RAM" macros, IP wizards and/or "megafunctions".

The more portable way is to find out how to infer them (e.g. write code where the tools go "Oh, I know that pattern! I can optimize that pattern into a RAM block!").

For Altera, have a look at http://www.gstitt.ece.ufl.edu/courses/spring10/eel4712/lectures/vhdl/qts_qii51007.pdf

For Xilinx have a look at https://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_1/ug901-vivado-synthesis.pdf,

The tools are very picky at how they match the patterns, the closer you get to the vendor's published code the more likely you are to get the result you really want.

There is nothing worse than changing your toolset, and realizing that you have used a design pattern that in 30+ files and it doesn't work. This usually shows up as the design not fitting, because it hasn't used hard blocks for RAM and multipliers. You then have to recode and retest everything again. (Yes, this happened on a video design that went from Altera to Xilinx).

I would even go as far as suggesting that any parts of the design where you do these sorts of things should be isolated out into a sub-directory of vendor specific code.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #55 on: June 17, 2017, 05:54:26 am »
Third party stand alone VHDL and Verilog stand-alone compilers do exist, though they are not my area & they may cost money.
Whether you choose Altera's Quartus of Xilinx free toolsuite & write a verilog, or vhdl code, the program you write will be compatible in both tool suites except when you try to use a vendor specific library.  In fact, your code is even more cross compatible than writing a C program for a PIC VS an Atmega.  Remember, your Verilog/VHDL code describes nothing more than clocked bolean logic, with inputs and outputs.  The FPGA vendor editor suites just allows you to wire your inputs and outputs of each of your Verilog/VHDL source codes to the pins of the FPGA.  Only that there are optimized IO pins in some cases like dedicated clock inputs, but this is the same for whichever FPGA type you choose.

Now, when I say multiple VHDL/verilog source codes, this means in 1 chip, you can wire multiple copies of your code, or multiple different codes wired together or to different IO pins, or anything you can imagine.  For example, in my FPGA based video scaler, I have verilog programs:

DDR3_Ram_sequencer.v  (State machine which drives the RAS/CAS/WE/DQS... and RD_RDY and WR_RDY and DQ_OE)
Ram_8port_priority_bridge.v  (Has 8 read address, 8 write address inputs, sends the next one in queque to the DDR3_ram Controller)
Video_Line_Cache_in.v   (works with the above 2 codes.v for DDR ram 128 bit access, takes an input video stream at 32 bit at input pixel_in clock speed)
Video_Line_Cache_out.v   (works with the above 2 codes.v for DDR ram 128 bit access, sends video out at 32 bit at pixel_out clock speed)
Video_color-space-converter.v  (Works on the 32 bit video pipe, inbetween the input/output pins and the Video_Line_Cache_xxx.v, has brightness, contrast, saturation & hue controls.)
MCU_pic24_emulator.v     (Uses onchip FPGA ram to run code for onscreen menus and system operations like listen to the Ethernet and front panel, instructs all the other .v modules which have configuration inputs.)
RS232_bidir-fifo_com_port.v
Master_Raster_Sync_Generator.v
Others....v

All these .v modules you may think of as a new digital IC and they can be wired to just IOs or between each other internally.
These .v programs (could be described as modules) I made will compile both in Altera's and Xilinx's IDE tools except for 2 minor inconveniences regarding setting up the custom PLL which differs in both chips and defining the FPGA's internal dual port ram memories since I want to use dedicated enhanced features.  But this is a lesser problem since these configured functions are nothing more than another verilog_special_memory.v file personalized to the vendor's chip which for example my MCU_pic24_emulator.v would be wired to.  But this shouldn't be anything you should worry about at this stage.
« Last Edit: June 17, 2017, 06:06:06 am by BrianHG »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #56 on: June 17, 2017, 08:46:42 am »
simulate it without picking some vendor tool? 

Well, here I use ModelSim,  but it's not the version included with Xilinx's tools, it's an external tool, and as editor & checker I use Sigasi, an other external tool. It's very productive as it has a deep understanding of what you write.

So, I write HDL with Sigasi, I simulate it with ModelSim, then I move to the Vendor's toolchain (Xilinx in my case) for two new purposes

-1- timing constraints and their analysis
-2- synthesis (and optionally, optimization)


 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Learning FPGAs: wrong approach?
« Reply #57 on: June 17, 2017, 08:59:58 am »
(I'm very pleased with the discussion that is being generated here.  A big "thank you" to everyone who is participating!)


Quote
Next step would be to learn one of the HDLs.

Once you've got the beginning of a grip on your chosen HDL, take the 'discrete' design you already made and implement the discrete parts you 'made up' in HDL, interconnect them in HDL, scribble a little HDL test-bed and hit the simulator.

The vendor tools for actual FPGAs can be quite a struggle to set up and get running with - not what you want at the 'hello world' stage. I'd recommend that if you're going Verilog that you grab the open source Icarus iverilog simulator

Wait!  I can write verilog/VHDL and simulate it without picking some vendor tool?  I was thinking that the only compiler/simulators around were in one vendor tool or another...  How does this work, without having the limitations of a particular chip in mind?   I just write my design files, and "later" move it to some vendor chip, tie in pin definitions and such, and see if it fits?  Very interesting!
There is a free one: GHDL. I use that to simulate VHDL which I later use in a Xilinx FPGA. However as usual with simulation you have to be aware that it is just as good as the stimuli you feed into it.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #58 on: June 17, 2017, 09:06:12 am »
p.s.
As I said before, there are some features which are vendor-specific.

e.g. Spartan6 comes with an useful built-in DDR controller. To use it ... you need to invoke an IP-wizard which automatically instantiates it for you, resulting an interface entity with the implementation hidden in a black block. It's hardware, implemented in hardware inside the fpga as special block which you can't change, you can only use it as Xilinx has designed.

Keep in mind, it's vendor-specific, and technology specific: not portable!

In this case, I take the interface entity, and I try to idealize its behavior into ModelSim, just to be able to simulate the whole system. Practically the DDR block is not simulated in details (at RTL level), I assume it works (Xilinx's homework), and it has been correctly instantiated (my homework), so I just add a large and ideally memory-block to ModelSim. 

Of course, then I have to verify these two hypothesis.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #59 on: June 17, 2017, 09:12:27 am »
GHDL

-1- it depends on GNAT, which is perpetually full of problems and bugs
-2- it doesn't cover the full vhdl specification, just a sub-set
-3- too much effort required since you need to adapt your source to it
-4- error-messages are silly, you can never understand what is wrong, you have to suppose
-5- stimuli are a mess, and very error prone as you have to write a lot of test-bench code
-6- which, especially points { 3, 4, 5}, reduces the productivity by five orders of magnitude

Conclusion:
GHDL is good if you don't have money, if you are a student and if your project is an university homework.

For professional projects done for business, (when someone checks your how long your job takes, and how complex it can go in a working-team) ModelSim is *THE* simulator one has to go.
« Last Edit: June 17, 2017, 09:59:01 am by legacy »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Learning FPGAs: wrong approach?
« Reply #60 on: June 17, 2017, 09:57:49 am »
If you simulate complete designs then going for Modelsim is a no-brainer but I don't simulate large designs. I only simulate small pieces and for that GHDL is good enough.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #61 on: June 17, 2017, 10:06:09 am »
small pieces and for that GHDL is good enough.

Even for small pieces, GHDL is defective for the above points. I spend three years on it, frankly I wish someone had pointed me out those points instead of making me to waste my time trying to fix/use it.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #62 on: June 17, 2017, 02:40:06 pm »
Vendor specific...

The video above that demonstrates how to install and use the Lattice toolchain is very good and as good a place to start as any.  However, right out of the gate, the author uses the internal oscillator provided on the chip and this absolutely won't be portable to any other device family.  The good news is that the MachX03 board itself does have an external 12 MHz oscillator.  What do you want to bet that the PLL used to kick up the speed won't be portable either?

I have decided to use the features provided and worry about porting later.  My hobby projects just aren't complex enough to worry about.  Portability is an illusion!  We can't even get the clock to work without vendor specific gadgets!

One thing I would hate is porting initialized BlockRAM.  I have written external programs that grab the memory contents from some file and write the entire VHDL file.  Just one more task when porting...

Back to the video... It covers:

1) Toolchain installation
2) License management - don't worry, the license is free!
3) Project creation
4) Verilog design entry
5) Testbench creation
6) Simulation
7) Synthesis
8) Pin assignment
9) Device programming
10) Virtual logic analyzer

Of course the coverage depth is quite shallow but it's a short video.  It is enough to get started!  The board itself is cheap enough, it's the shipping that I snivel about!



« Last Edit: June 17, 2017, 04:30:33 pm by rstofer »
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: Learning FPGAs: wrong approach?
« Reply #63 on: June 17, 2017, 02:52:26 pm »
it's the shipping that I snivel about!

I get free shipping (from the US to the UK), with Digikey, who sell it. As long as the order value, is at least £33. Which is quite easy to achieve.
Hopefully within the US, it is similar.

But too late for now, as you seemed to say you already bought it from Lattice.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #64 on: June 17, 2017, 04:29:56 pm »
it's the shipping that I snivel about!

I get free shipping (from the US to the UK), with Digikey, who sell it. As long as the order value, is at least £33. Which is quite easy to achieve.
Hopefully within the US, it is similar.

But too late for now, as you seemed to say you already bought it from Lattice.

I don't get free shipping from Digikey but it is usually Priority Mail and that is very cheap and FAST.  I looked for stock at Mouser and they didn't have any.  I didn't look at Digikey and probably should have as they do have stock.  All my bad...

Digikey is a great supplier.


Late breaking news:  The board has shipped - from Mouser.  The very place I looked for stock.  I must have had a serious bout of 'senior moments' yesterday!
« Last Edit: June 17, 2017, 04:33:56 pm by rstofer »
 
The following users thanked this post: MK14

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #65 on: June 17, 2017, 04:56:31 pm »
Portability is an illusion!  We can't even get the clock to work without vendor specific gadgets!

Yup, sadly the Truth, especially if you use the Digital Clock Manager (DCM) primitive in Xilinx FPGA parts to implement delay locked loops, PLLs, digital frequency synthesizers, digital phase shifters, etc. This point is also relevant during timing-constraints analysis, which is both vendor and device specific, and it's a MUST-BE-DONE if you have to check low-level requirements from your customers.

p.s.
why Lattice? Never used, I am curious.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: Learning FPGAs: wrong approach?
« Reply #66 on: June 17, 2017, 05:03:31 pm »
I don't get free shipping from Digikey but it is usually Priority Mail and that is very cheap and FAST.  I looked for stock at Mouser and they didn't have any.  I didn't look at Digikey and probably should have as they do have stock.  All my bad...

Digikey is a great supplier.


Late breaking news:  The board has shipped - from Mouser.  The very place I looked for stock.  I must have had a serious bout of 'senior moments' yesterday!

Don't worry, similar/same things would wind me up. I find the Amazon system of almost constantly fluctuating prices, on many things, annoying.

Sometimes I buy something, and while it is being shipped, the price drops, and I find that annoying. But I'm kind of philosophical about it, and accept I will gain sometimes, and lose other times.

I know in theory, some people claim you can hassle Amazon customer services, and get the price dropped, on your order. Because the price dropped just after you ordered it. But I don't want to bother them and/or waste their and my time, over what is usually quite small amounts of money.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #67 on: June 17, 2017, 05:35:03 pm »

p.s.
why Lattice? Never used, I am curious.


You're right, why Lattice?  Beats me...  I have a large assortment of Digilent-Xilinx boards and I certainly don't need a low end board.  So, why am I interested?

Well, I watched the video.  I REALLY like the toolchain.  The licensing scheme is pretty painless and not nearly as obtuse as Xilinx's.  I like the way pins are configured with a spreadsheet.  I like the touch and feel of Diamond as it is similar to Xilinx's ISE (sort of).  In any event, the startup curve is a lot flatter than Vivado's (does anybody really understand the .XDC file?).  I like the Just In Time syntax analysis - save the file and syntax analysis is automatic and FAST (at least for small projects).

I can see the value in a $25 startup board;  I don't personally have any use for it but I'm sure something will come up.  I like the high pin count on headers, I don't really like Digilent's PMOD connectors, there simply aren't enough pins.  I do understand that the board has no peripheral gadgets except a bank of LEDs.  If I need SRAM, I'm on my own!

For the newcomers, this setup is all they really need to start creating logic.  The regrettable lack of switches and buttons is something of a bother but I imagine they can figure out something.  If they can't, well, maybe golf is a better hobby.

In the back of my mind, I am thinking about Caxton C Foster's 'minicomputer' - BLUE.  I have been thinking about this trivial 16 bit CPU for about 40 years.  As a CPU, it implements only the most trivial operations but it's a good first project.  In my case, it is just something I want to play with.  One thing it needs is a lot of IO for the switches and LEDs.  IO Expanders are one option but for the MachXO3 board, there is no need.  There are plenty of pins.  Maybe I'll finally get around to implementing it.  Al Williams https://www.awce.com/ did a vastly expanded version a few years ago but I don't see it around on his site.

ETA:  The BLUE project is available on OpenCores http://opencores.org/project,blue

Why do all this?  Well, I hope my grandson gets into EE or CS as a major.  It might be useful to have a trivial computer around just to discuss elementary architecture and 'the way it used to be'.  I also suspect that Vivado will sink a newcomer.  Just guessing...

« Last Edit: June 17, 2017, 05:48:27 pm by rstofer »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #68 on: June 17, 2017, 05:40:34 pm »
But I don't want to bother them and/or waste their and my time, over what is usually quite small amounts of money.

In the bigger scheme of things, the amount is trivial.  If I didn't want to pay it, I wouldn't have bought it.  Money is not one of my larger problems.  Old age is a much larger concern.
 
The following users thanked this post: MK14

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Learning FPGAs: wrong approach?
« Reply #69 on: June 17, 2017, 06:09:09 pm »
I like the way pins are configured with a spreadsheet.  I like the touch and feel of Diamond as it is similar to Xilinx's ISE (sort of).  In any event, the startup curve is a lot flatter than Vivado's (does anybody really understand the .XDC file?).

You can do this in Vivado too. Open "Elaborated Design" and it has a similar pin table. Once you select pins, it'll create an XDC file with the definitions (or update an existing one). You'll have do re-run synthesis though :(

I like the Just In Time syntax analysis - save the file and syntax analysis is automatic and FAST (at least for small projects).

Vivado does continuous syntax check for VHDL files. If something is wrong it draws a red squiggle and you can hover over it to see the error message. It is fast enough for me. Very handy when the synthesis is so slow.

In the Lattice video, the synthesis is rather fast, but I couldn't figure out if it was normal speed or fast forward.

 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: Learning FPGAs: wrong approach?
« Reply #70 on: June 17, 2017, 06:12:19 pm »
I like the way pins are configured with a spreadsheet.  I like the touch and feel of Diamond as it is similar to Xilinx's ISE (sort of).  In any event, the startup curve is a lot flatter than Vivado's (does anybody really understand the .XDC file?).

You can do this in Vivado too. Open "Elaborated Design" and it has a similar pin table. Once you select pins, it'll create an XDC file with the definitions (or update an existing one). You'll have do re-run synthesis though :(

I like the Just In Time syntax analysis - save the file and syntax analysis is automatic and FAST (at least for small projects).

Vivado does continuous syntax check for VHDL files. If something is wrong it draws a red squiggle and you can hover over it to see the error message. It is fast enough for me. Very handy when the synthesis is so slow.

In the Lattice video, the synthesis is rather fast, but I couldn't figure out if it was normal speed or fast forward.
Diamond will synthesise &  place & route a simple design in about 10 seconds.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Learning FPGAs: wrong approach?
« Reply #71 on: June 17, 2017, 06:18:56 pm »
If you have the possibility ( = if your boss/customers pay it ), switch to Sigasi. It's the Eclipse-like for HDL :D
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Learning FPGAs: wrong approach?
« Reply #72 on: June 17, 2017, 06:50:49 pm »
If you have the possibility ( = if your boss/customers pay it ), switch to Sigasi. It's the Eclipse-like for HDL :D
Sigasi is nice but what I don't like is the time limited node locked license. For me such software is a no-go. What if they go out of business or my PC breaks just when I need to finish a project and I can't affort to wait until they change the license to a new PC? It would be great if Sigasi offered a perpetual license and someone cracked it so it is no longer node locked. I'd buy it in a heartbeat.

A reasonable alternative is the (open source) Eclipse plugin called Veditor. It can do much less than Sigasi but combined with Eclipse it is lightyears better than the editor in Xilinx ISE.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #73 on: June 17, 2017, 06:53:41 pm »
In the Lattice video, the synthesis is rather fast, but I couldn't figure out if it was normal speed or fast forward.

For the simple counter LEDs, synthesis is about 1/2 second and building both the bitstream and JEDEC file, from 'Rerun All', takes about 15 seconds.  Pretty impressive!
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Learning FPGAs: wrong approach?
« Reply #74 on: June 17, 2017, 06:55:42 pm »
If you have the possibility ( = if your boss/customers pay it ), switch to Sigasi. It's the Eclipse-like for HDL :D

I'll check with Social Security and see what they have to say (not!).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf