Total beginner at FPGA

[asmi]

Yes,

Using FPGA which has ZERO pins that can reach even 1Gpbs? 

and this is why I recommend to not use boards with MEMS oscillator. You can catch instability and other issues with it and it's not obvious what is the root of cause, it's hard realize that the floating bug happens due to a poor clock from MEMS oscillator.

BS. I have implemented designs going as high as 8 Gbps per differential pair using MEMS oscillator and had zero issues with dropped links. So if you can't do that - you are doing it wrong, and MEMS is 100% not a problem.

[asmi]

do you think that the powerful and very expensive FPGA with a lot of resources is really what beginner needs for experiments? It's easy to burn some pin on FPGA. If you use cheap Chinese starter kit board, you can just buy a new one. Because it's not expensive.

But what happens if you bought 1000 USD FPGA board and burned it due to a wrong connection?

I've NEVER burned a single pin in all of my FPGA experiments and projects. So refer to my previous post - if you did, you are doing it wrong.
But then again - I don't actually have any 1000 USD boards. The most expensive one I got is Genesys 2, which is just 999 USD This is the board I used to reach 8 Gbps per diff pair, as Artix can only go as high as 6 Gbps. Though I have plans to make SFP+ FMC board which should allow me to reach full 10G per channel. If only I would have enough spare time for that

[JohnnyMalaria]

https://www.bugblat.com/products/pif/index.html

a powerful FPGA (7000 LUTs)

Why laugh? For a beginner, it's good enough. $49.

God, I hate smug buggers.

[asmi]

Why laugh? For a beginner, it's good enough. $49.

It's fine for beginners, but calling it "powerful" is just wrong. Call it for what it really is - low end device good enough for very simple projects.

[radiolistener]

I have implemented designs going as high as 8 Gbps per differential pair using MEMS oscillator and had zero issues with dropped links. So if you can't do that - you are doing it wrong, and MEMS is 100% not a problem.

if your circuit has a single clock with no asynchronous lines, you can do that and it will works at some conditions with proper PCB layout. But I tried this MEMS oscillator to wire FPGA with external serial port (RX/TX line with start/stop bits) and it has transfer errors at megabit speed. This is not what beginner needs to fight with.

Such board needs good and stable oscillator for different experiments, for example serial communication or frequency meter is a nice project for a beginner.

[asmi]

if your circuit has a single clock with no asynchronous lines, you can do that and it will works at some conditions with proper PCB layout. But I tried this MEMS oscillator to wire FPGA with external serial port (RX/TX line with start/stop bits) and it has transfer errors at megabit speed. This is not what beginner needs to fight with.

So your problem was crappy layout, not oscillator. At 1 Mbps even really bad oscillator is going to be just fine, as even super bad ones have jitter in the order of 100's of ps. So for 1000 ns period even 1 ns jitter (which I've never seen in person even on a cheap-ass Chinese boards) will make zero difference because you are going to be sampling at 500 ns into the change.

Such board needs good and stable oscillator for different experiments, for example serial communication or frequency meter is a nice project for a beginner.

No you don't. For frequency meter that may be, but everybody's interests are different. For example, most of my FPGA projects were about realtime image and video processing, CV and stuff like that, for that kind of designs the type of oscillator makes no difference because all processing is done in digital domain. Same for serial links - proper layout is going to be much more critical than the oscillator stability. Take a look at the project in my signature - it's got a few 1.45 Gbps serial links (for HDMI 1080p), and they work with no problems using ordinary MEMS oscillator to synthesize required frequencies for the kind of bitrate that Cyclone 4 can only dream of. To be sure, MCMM block that I use inside that FPGA has a jitter filter, which helps, and it makes this debate even more pointless.

[radiolistener]

So your problem was crappy layout, not oscillator. At 1 Mbps even really bad oscillator is going to be just fine

1 Mbps is too slow, I wanted to use at least 10-12 MBps.

[asmi]

1 Mbps is too slow, I wanted to use at least 10-12 MBps, but it has transfer errors even at 3 MBps.

Still. I recently designed small addon board for the board from my signature with 100 MBit ethernet PHY, so it has 25 MHz MII interface going over regular 0.1" pin header with no length matching nor controlled impedance, and that interface works at full speed with no errors.
So if you had bit errors at 3 Mbps, your sampling point was probably too close to data transition points. For 10 Mbps we're talking 100 ns periods, so you can have your sampling point at 25 ns and that will guarantee no bit errors regardless of jitter (unless you had like 25 ns of jitter which is just ridiculous, and no oscillator is going to have anything near it). Heck, I had 50 MHz SPI working over the breadboard with flying leads as connections, so the was definitely something wrong with your design. If you want to get to the bottom of this, begin a new thread and hopefully we can figure it out. But one thing is for certain - whatever the reason is, it's not related to the clock itself.

[radiolistener]

Also the bad thing with MEMS is that when you produce 400 MHz and above with PLL, it works very unstable. If you want to use your FPGA board as a signal generator, it works very poor from MEMS oscillator. Just see the screenshot.

Such instability is unacceptable even for amateur purposes.

[asmi]

Also the bad thing with MEMS is that when you produce 400 MHz and above with PLL, it works very unstable. If you want to use your FPGA board as a signal generator, it works very poor from MEMS oscillator. Just see the screenshot.

Again, the board in my signature generates bit clock of 742.5 MHz for HDMI output from input MEMS oscillator running at 100 MHz, and guess what - interface works just fine. So you are looking for a problem in the wrong place.

[radiolistener]

Again, the board in my signature generates bit clock of 742.5 MHz for HDMI output from input MEMS oscillator

yes, it generates, you can see it on the screenshot above. But do you see how is dirty and unstable signal is when you clock FPGA from MEMS oscillator?

For comparison, here is TCXO 50MHz feeded to PLL to produce the same 400 MHz on QMTech starter kit board.

Do you see the difference between MEMS and TCXO?

[asmi]

Do you see the difference between MEMS and TCXO?

I don't see any difference on my monitor, which shows stable HDMI video stream with no problems, and that is the only thing that matters. Which was my point all along. If design works with MEMS, there is exactly zero reasons to bother with changing oscillators. Besides, how many FPGA devboards do you know which have TCXOs onboard? I can't think of a single one. You might want to think about the reasons for that. And before you say "cost", I urge you to take a look at something like Xilinx KC705, which cost over 1500 USD, and have interfaces going as far as 10 Gbps, yet all they have is regular MEMS oscillators.
Again, you are looking for a problem in the wrong place. Clock jitter doesn't matter in 99% of cases, as long as it's not ridiculously large. Anything lower than 1% is going to be just fine.

[radiolistener]

If design works with MEMS, there is exactly zero reasons to bother with changing oscillators.

But starter kit is not intended for a limited design. It should works good for different tasks, include frequency meter project and analog data acquisition and processing from high speed ADC/DAC

Again, you are looking for a problem in the wrong place. Clock jitter doesn't matter in 99% of cases, as long as it's not ridiculously large. Anything lower than 1% is going to be just fine.

For me the clock jitter and phase noise matters very much, because I'm using it to produce DAC output. Any clock jitter leads to worse dynamic range and spectral purity of the output signal. From my point of view this is the main purpose of FPGA - fast DSP working at tens and hundred MHz speed to process ADC/DAC data and transfer it from and to PC at high speed.

[BrianHG]

Do you see the difference between MEMS and TCXO?

I don't see any difference on my monitor, which shows stable HDMI video stream with no problems, and that is the only thing that matters.

Warning, many HDMI screens support 'spread spectrum HDMI' meaning any crappy clock will work.  Can you say that your monitor supports spread spectrum HDMI or not?

If you were to plug your low quality source clock into an HDMI monitor which doesn't support spread spectrum HDMI, will you get jittery pixel errors?

I ran into this problem 10 years ago.  Many large screen Sharp TVs would work perfectly, but, some Sony TV had crap jitter around the pixels.  It took a month to discover all I had to do was disable spread-spectrum and the picture became perfect on the Sony TVs at the time.

[asmi]

Warning, many HDMI screens support 'spread spectrum HDMI' meaning any crappy clock will work.  Can you say that your monitor supports spread spectrum HDMI or not?

We're talking about <0.01 UI jitter as "bad clock". It's not really bad enough to matter.

[Canis Dirus Leidy]

And I would have to buy 10 starter kits to come anywhere close to an Artix 7 100T variant in terms of LUTs and BlockRAM (my two important characteristics).

Not really, Their (QMTech's) starter kit version with XC7A100T costs just $100.

[Bud]

Also the bad thing with MEMS is that when you produce 400 MHz and above with PLL, it works very unstable. If you want to use your FPGA board as a signal generator, it works very poor from MEMS oscillator. Just see the screenshot.

Such instability is unacceptable even for amateur purposes.

Seems an unlocked PLL to me. Poor PLL design.

Edit: Poor PLL loop filter design.

[emece67]

.

[rstofer]

a powerful FPGA (7000 LUTs)

do you think that the powerful and very expensive FPGA with a lot of resources is really what beginner needs for experiments? It's easy to burn some pin on FPGA. If you use cheap Chinese starter kit board, you can just buy a new one. Because it's not expensive.

But what happens if you bought 1000 USD FPGA board and burned it due to a wrong connection?

Which is one reason for putting 330 Ohm resistors in series with all IO pins.  It takes the worry out of short circuits and it also helps damp down reflections.

For the Nexys A7 board, Digilent is using 200 Ohm resistors and clamp diodes on the pins (Page 1, upper right corner).  I certainly wouldn't quibble about the lower value.

https://reference.digilentinc.com/_media/reference/programmable-logic/nexys-a7/nexys-a7-sch.pdf

These "student" boards are designed to help reduce mortality.

[rstofer]

http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdf

Look at Figure C3 for a block diagram of the LC3 CPU.  The CPU isn't the point of this reply, the diagram is.

Notice the number of MUXes:  MARMUX, PCMUX, ADDR1MUX, ADDR2MUX, SR2MUX, INMUX and that MUX with the MIOEN control signal.  You would think that being able to code MUXen is an important task - and it is!  There's a straight out adder and an ALU - coding those would be the next topic.  The adder is trivial and the ALU is pretty simple.  We also have a register file with is actually two files (arrays) in parallel.  When we load a register, we write both copies but we can read them out separately so we can do R3 = R1 + R2 in one cycle.  We just read R1 from one copy and R2 from the other copy and present them to the ALU (and the SR2MUX).

These are the kinds of things you need to learn how to code.  All digital systems are built from these basic blocks and the complexity of a system is just a count of the number of blocks.

On page 2 there is a transition diagram.  You use that to create the Finite State Machine that makes the CPU work.  Every numbered state is duplicated exactly in some HDL and, in my case, I used an integer for the state type so I could match the state numbers on the diagram.  It takes a little time and thought to realize that every control signal is generated in that state machine.  Once you think about it, it's both obvious and brilliant!

Find a tutorial that teaches you how to code an FSM.  I prefer the two process approach, the one process and three process approaches will also work.  You have no idea what I'm going on about but don't worry!  It will be covered in great detail when you start on the tutorials.  Hint:  Don't forget to provide default values for all outputs of the two and three process models.  Again, this will be discussed in the tutorial (if it is worthwhile).

There's nothing on that page that resembles C++ although I could create a class for every block type and write some sequential code that would do in software what this CPU does in hardware.  It might even be an interesting experiment.  Hint:  It's been done before...  My PDP11/70s are software emulations running on a Raspberry Pi and they are faster than the real hardware.  No, I didn't write the code.

https://obsolescence.wixsite.com/obsolescence/pidp-11

Bottom line:  Find tutorials that will teach you how to code the basic blocks.  We just keep using the same blocks, over and over.  Different signals, different widths but, fundamentally, the same blocks.

Here are a couple of example MUXen:

Code: [Select]

    --PC Mux Control
    process(PCplusOne, PCadderOutput, mBus, PCSelect)
    begin
        case PCSelect is
            when PCplus1        => PCmuxOutput <= PCplusOne;
            when PCadder        => PCmuxOutput <= PCadderOutput;
            when PCmBus         => PCmuxOutput <= mBus;
            when others         => PCmuxOutput <= (others => '0');
        end case;
    end process;
   
    -- MAR Mux Control
    process(PCadderOutput, Zext, MARSelect)
    begin
        case MARSelect is
            when MARadder       => MARmuxOutput <= PCadderOutput;
            when MARzext        => MARmuxOutput <= Zext;
            when others         => MARmuxOutput <= (others => '0');
        end case;
    end process;

See how straightforward this stuff is?  It's the same code, over and over!

[rstofer]

In terms of VHDL, this book is pretty good and it's FREE!

http://freerangefactory.org/pdf/df344hdh4h8kjfh3500ft2/free_range_vhdl.pdf

The FSM discussion on page 93 is worth studying.  Remember when I said to provide default values to all outputs in a two process FSM?  Well, Z1 <= '0' (line 3 of comb_proc) is that default value and you have to provide defaults for every output of the FSM.  It's easy to forget and, more likely than not, nothing works!  There's a reason I know this and keep mentioning it.  If the synthesizer says you have inferred latches, that's where they are - outputs which aren't defined in every state and have no default value.  Every time you expand the capability of the FSM, you are probably creating a new output and you need to provide a default value.

See bullet item on page 95

An example of default values from my LC3 project:

Code: [Select]

       -- set default values for all signals
        GateBusSelect   <= GatePC;
        MIOenable       <= '0';
        LD_MAR          <= '0';
        LD_MDR          <= '0';
        LD_IR           <= '0';
        LD_BEN          <= '0';
        LD_PC           <= '0';
        LD_Reg          <= '0';
        LD_CC           <= '0';
        LD_Privilege    <= '0';
        LD_Priority     <= '0';
        LD_PSR          <= '0';
        LD_SavedUSP     <= '0';
        LD_SavedSSP     <= '0';
        LD_VectorAddr   <= '0';
        PCselect        <= PCplus1;
        MARSelect       <= MARzext;
        Addr1Select     <= Addr1PC;
        Addr2Select     <= Addr2Zero;
        SR2select       <= SR2OutSel;
        SR1addrSelect   <= SR1usesSR1;
        ALUop           <= ALUpassA;
        DRaddrSelect    <= DRusesDR;
        MemWr           <= '0';
        SPselect        <= SPminusOnesel;
        VectorMux       <= "00";
        Privilege       <= '0';


[asmi]

I think nandland has the best tutorial series for total beginners. In my opinion his board is worth buying to support the author and so that you can follow tutorials and experiment with them. And they are bilingual, having sections for both Verilog and VHDL, so you can get a glimpse at both.

[asmi]

Not really, Their (QMTech's) starter kit version with XC7A100T costs just $100.

This is a typical Chinese crap board designed by a mindless drone who obviously had no idea what he was doing Because if he had even a single working brain cell, he would never placed a 3 Amps DC-DC converter for a device which can draw up to 7 Amps of current, not to mention there having zero provisions for any type of thermal control despite the fact that this FPGA can dissipate up to 10 W of power, and there is no way it won't overheat without some sort of cooling.
And this is exactly why I always recommend beginners to avoid these garbage boards in favor of name brands at least until they have enough experience and knowledge to know all of the above so they can judge by themselves if board is designed properly and will actually do what they think it can do.

[rstofer]

And I would have to buy 10 starter kits to come anywhere close to an Artix 7 100T variant in terms of LUTs and BlockRAM (my two important characteristics).

Not really, Their (QMTech's) starter kit version with XC7A100T costs just $100.

But where is the 8 digit 7-segment display to hold the Accumulator and Program Counter displays?
How about the 16 switches for Console Entry Switches?
Or the 16 LEDs for status information?
Or even the push buttons for Run, Halt and Single Step?

I realize that not everybody needs those features and I also realize the Digilent board is expensive, but I do need the features and I don't care about the extra cost.  Rigging up something off the board is certainly possible.  I have used one of the Maxim display chips to create 16 7-segment digits over an SPI bus and it worked very well.  I also used a port expander to collect up 16 console entry switches over SPI.  I would prefer to have the gadgets on the board rather than laying on the bench.  Or worse, group mounted on a plywood backboard.  Actually, that worked out rather well.  Considering...

Another use for the console switches:  Implement breakpoints based on the PC.  This is sometimes useful when bringing up an OS.  Once the CPU has hit the breakpoint, resort to single stepping.  The status LEDs will be helpful!

[SiliconWizard]

QMTECH boards are OK if you know what you're doing, but I agree they are not that well adapted to beginners.

As to their design itself - from what I've seen (I can only talk about the ones with Xilinx FPGAs), they are OK for the lower end parts (Spartan 6 up to LX25, Artix 7 up to 35T I'd say), but beyond that, nope. The reason is that, as said above, power supplies are not properly sized, there is not heat management, and there is overall poor decoupling.

So yes, the board with an Artix 7-100T is basically designed just like the ones with lower end parts, and you won't be able to do anything serious with it in a reliable way, unless maybe you're designing very low frequency stuff.