Lattice Mach XO2 strange behaviour in VHDL

[Detzi]

You can divide by more than this I think, but there's a limit indeed since it's based on a VCO. (It's just a matter of getting to know how to use the PLL IP which is a bit confusing. And don't forget to click on the "Calculate" button in the IP dialog (and you have to scroll down to see it) when you change any parameter and before you generate the IP, otherwise it doesn't take your changes into account.)

As I suggested, you can embed an additional prescaler inside your serializer.

I used this guide to set up the PLL:  https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwilppTI2craAhVMLVAKHUDkDa4QFggoMAA&url=http%3A%2F%2Fwww.latticesemi.com%2F~%2Fmedia%2FLatticeSemi%2FDocuments%2FApplicationNotes%2FMO%2FMachXO2sysCLOCKPLLDesignandUsageGuide.pdf%3Fdocument_id%3D39080&usg=AOvVaw3mnRk3P2F6W_qicoBMOLtI
i tried to calculate the Output frequency with the equations given but my Output doesn't match, so i guess i didn't configure it right. It also gave me an eror where it says That my Frequency is too small "0.015 MHz" and it complains also about a "2.08Mhz" Input freuency. But i am confident that it is just a matter of time.

For the counter, if i get you right, what you suggest is instead of putting the same "Prescaler" in its own Component and distributing its output to all necessary components, i should create it inside of each component, feeded by say the "sys_clk" created by the "intOSC", and then driving this single Component on its Output.
When i do this i would end up with a bunch of slightly asychron components, because of the uneven propagation times ( right? ). Is it then necessary or at least a good habit to synchronise the output of the whole component back on the "rising_edge" of "sys_clk"?

Not really. But I think using a simple bit counter instead of this extra bit in the data register to test for the end of transmission would be much easier to read (and not necessarily heavier: it would take only 5 bits instead of having to compare 24 bits.)

You're testing this:

Code: [Select]

if(data_register(size-1 downto 0)=0) then
and later on this:

Code: [Select]

if (data_register(size downto 0)=0) then
I admit I got confused upon the first reading of this process.

I like the counter idea and already thought about it, because it could deliver me a almost empty bit its actually the better option here...The "size+-1"-Thing gets me confused sometimes too.

Ok I tried your project on my board and the Sync output seems fine. It goes low for the duration of 24 bits, and then back high. Are you sure you didn't have a probe contact issue?

What I modified though is the PLL. Got an error saying that the min output freq was 1.5 MHz or something, so I set 4 as a divider, which gives 1.75 MHz @7 Mhz osc.

I do not have the hardware here at the moment, so i can't try now. But i will on Monday, it would't surprise me if it would be so allthough the probe is stuck on a .1" header with a proper female type.

Now that you read a bit of my code and solved my problem, can you recomend a book that can help me improve? I don't know how i could not have stept into this trap without someone telling me.

Regardless it's really awesome that you helped me! I don't think i could have figured out this one by myself! Thank You!

[SiliconWizard]

i tried to calculate the Output frequency with the equations given but my Output doesn't match, so i guess i didn't configure it right. It also gave me an eror where it says That my Frequency is too small "0.015 MHz" and it complains also about a "2.08Mhz" Input freuency. But i am confident that it is just a matter of time.

Well, as this is a PLL, it has a limited input and output frequency range, so it's kind of hard to get very low frequencies with it. You could use an external clock, which I would suggest if you really need very low frequency clocks. You can feed the FPGA an external clock and not use the internal oscillator.

For the counter, if i get you right, what you suggest is instead of putting the same "Prescaler" in its own Component and distributing its output to all necessary components, i should create it inside of each component, feeded by say the "sys_clk" created by the "intOSC", and then driving this single Component on its Output.
When i do this i would end up with a bunch of slightly asychron components, because of the uneven propagation times ( right? ). Is it then necessary or at least a good habit to synchronise the output of the whole component back on the "rising_edge" of "sys_clk"?

Nope. Your signals would all be synchronized to the same clock, unless there are timing violations (such as setup or hold time) that the tools will warn you about.
Again, clocks are very different beasts than other signals when it comes to synchronization. It's not very easy to understand why at first.

I'll try to post an example of a modified version of your serializer to show you what I meant.

Now that you read a bit of my code and solved my problem, can you recomend a book that can help me improve? I don't know how i could not have stept into this trap without someone telling me.

There's a whole lot of books on digital design. Some pitfalls are kinda specific to FPGAs though, so you may find it interesting to read some application notes from FPGA vendors.
For instance, Lattice has a "Timing Closure" document that you may find useful: http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/RZ/Timing_Closure_Document.pdf?document_id=45588

For VHDL, although it shouldn't be your only source, the Free Range VHDL book is free and well regarded.

[SiliconWizard]

Attached is the modified serializer, along with the modified top-level module to accomodate for some interface changes.

As you can see, the serializer itself generates the serial clock along with the data output. (Again the clock output can be directed to an IO but you should avoid using it for clocking other processes.)
It has the added benefit of generating the serial clock only when the serializer is sending data, which is the usual behavior. I also added a guarding feature - preventing it from interrupting an ongoing transmit if you ever try to "set" a new data word while it's transmitting. You could even make it more flexible by adding generics to allow for different clock phase/polarity - should be pretty straighforward.

You can replace the two files in your project. I didn't test it extensively, but it seems to work fine.

[Detzi]

Attached is the modified serializer, along with the modified top-level module to accomodate for some interface changes.

As you can see, the serializer itself generates the serial clock along with the data output. (Again the clock output can be directed to an IO but you should avoid using it for clocking other processes.)
It has the added benefit of generating the serial clock only when the serializer is sending data, which is the usual behavior. I also added a guarding feature - preventing it from interrupting an ongoing transmit if you ever try to "set" a new data word while it's transmitting. You could even make it more flexible by adding generics to allow for different clock phase/polarity - should be pretty straighforward.

You can replace the two files in your project. I didn't test it extensively, but it seems to work fine.

That is really kind of you i will have a look at it soon.

There's a whole lot of books on digital design. Some pitfalls are kinda specific to FPGAs though, so you may find it interesting to read some application notes from FPGA vendors.
For instance, Lattice has a "Timing Closure" document that you may find useful: http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/RZ/Timing_Closure_Document.pdf?document_id=45588

For VHDL, although it shouldn't be your only source, the Free Range VHDL book is free and well regarded.

I actually had found this book myself, but only read the first three chapters, it seems to have a bit of a slow start, so i got bored and tossed it. But if you recomend it, i maybe give it a second shot.

Ok I tried your project on my board and the Sync output seems fine. It goes low for the duration of 24 bits, and then back high. Are you sure you didn't have a probe contact issue?

What I modified though is the PLL. Got an error saying that the min output freq was 1.5 MHz or something, so I set 4 as a divider, which gives 1.75 MHz @7 Mhz osc.

I do not have the hardware here at the moment, so i can't try now. But i will on Monday, it would't surprise me if it would be so allthough the probe is stuck on a .1" header with a proper female type.

So it was no contact issues it was picked up noise, most likely from the nearby clock lead...  lesson learned the hard way.

[SiliconWizard]

For VHDL, although it shouldn't be your only source, the Free Range VHDL book is free and well regarded.

I actually had found this book myself, but only read the first three chapters, it seems to have a bit of a slow start, so i got bored and tossed it. But if you recomend it, i maybe give it a second shot.

Well, it's not ideal and addresses a large audience, but you could "fast forward" and learn a few things though.
I have never stumbled upon *the one* book that sums it all nicely. Your best bet will be a collection of various sources. Which is good, otherwise you may find yourself trapped in the biases of one specific author. And you'll quickly find out that digital designers are ones of the most stubborn people out there. 

Another "classic" book is: "The designer's guide to VHDL" - Morgan Kauffman, which I find good but contains occasional outdated stuff.

I also suggest reading the latest VHDL standard (1076-2008) if you can get ahold of it (official versions are expensive). Always good to get your information from the official reference.

Also, I'd suggest learning to use test benches - they are invaluable and pretty much mandatory for verification & validation activities.

So it was no contact issues it was picked up noise, most likely from the nearby clock lead...  lesson learned the hard way.

To pick up such high levels of noise means that either you had a contact issue (which you're stating you weren't), or your ground connection was not right (ground loop), which would be typical if you connect your probe's ground to a "remote" ground point (best practice is to connect it to a ground point as close to your signal as you can).

On some occasions, the ground clip's lead of a probe itself can form a loop from which you can get inductively coupled noise from.