Lattice Mach XO2 strange behaviour in VHDL - Page 1
Forum section: electronics / general

author: Detzi
author_rank: Regular Contributor
timestamp: April 19, 2018, 08:05:03 am
content: Hi there,i have set up this Lattice breakout board:http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/MachXO2BreakoutBoard, one of the older ones with the 'LCMXO2-1200ZE-1TG144' on it. I wanted to create a simple Parallel in Serial out shift register in order to get Data in a DAC.I came quite far ( i guess) but when i setup the prescaler for the system Clock (osc_clk) to generate the ''Component Clock'' (compclk) and a then a second prescaler to generate the "transmission clock" (sck_clk) i ran into a problem that i can't figure out. Now i routed osc_clk, sck_clk and compclk to pins in order to measure the generated clocks. The scope shows now "osc_clk" and "compclk" fine but sck_clk is odd. Where it semms, it should be '0' its all good but when it shall went to a steady '1' it instead begins to clock with half the osc_clk. The rising edge seems to be where it should and if the clocking part would be a steady one, the frequency would be correct. But the on time is not half a wavecycle rather than a short pulse. What bugs me most ist that the code used for both prescalers are except the Names absolutely the same. I Also checked for differences in my toplayer, but the only one is the Prescale Value, which seems to has no effect on the Generated clock despite altering the generatet burst frequency. I know this is (should be)a simple task but i just don't get it.I attached a few Pictures of all described and of course the used code (as whole project). I am using Lattice Diamond Version(64-bit) 3.7.0.96.1.Can somebody explain me what is going on here?I am, after all, quite new to vhdl and haven't done a lot with it.Thanks in foreward!

author: hamster_nz
author_rank: Super Contributor
timestamp: April 19, 2018, 10:15:17 am
content: Your 'Prescaler' is much heavier on variables than I am use to. I am also not used to variables holding state. I had to simulate it, but it looks fine.I would have also changed it so that the range for counter is one less (so if divider is 4, then it is only 0 to 3):Code:beginPrescaler : process (compclk)variable counter : natural range 0 to divider-1 :=0;variable outx : std_logic := '0';beginif (rising_edge(compclk)) thenif counter=divider-1 thenoutx := not outx;counter:=0;elsecounter:=counter+1;end if;end if;clkout <= outx;end process Prescaler;In PISOsr, you should set the initial value of data_register and dout:Code:dout: out std_logic := '0'--Data Output....variable data_register : std_logic_vector(size+1 downto 0) := (others => '0');I couldn't get 'trigger' to work, so I rewrote it with what it seems you are trying to do, but closer to my usual style:Code:library ieee;use ieee.std_logic_1164.all;use ieee.std_logic_unsigned.all;use ieee.numeric_std.all;entity Trigger isgeneric (cycles : natural := 1);port(compclk: in std_logic;key : in std_logic;--Clock with witch the Data are Outputcmd : out std_logic := '0'--Enables the Clock Input);end Trigger;architecture Trigger_arch of Trigger issignal debounce : integer range 0 to cycles-1 :=0;beginTrigger : process (compclk)beginif (rising_edge(compclk) ) thenif debounce = cycles-1 thencmd <= '1';debounce <= 0;elsecmd <= '0';if debounce = 0 thenif(key='1') thendebounce <= 1;end if;elsif debounce > 0 thendebounce <= debounce+1;end if;end if;end if;end process Trigger;end Trigger_arch;But here is the most likely problem - the Serialiser and Trigger are being driven by compclk, when maybe it should be driven by sck_clk?Code:i_PISOsr:PISOsrgeneric map (size => 23)port map(compclk => compclk,assign=> start,empty=> RegEmpty,din => DACData,--Data Inputdout=> SOut--Data Output);To me it looks like the serialiser (PISOsr) is sending out a very short burst of data very fast, much faster than SCLK.Also, the input to trigger (key) is not synchronized by back-to-back flipflops. You might end up with intermittent behavior.A really the cause for your problems may be that you have made three clocks where you only really need one.As for the traces, what you say is SCLK looks very much like SOut in my simulation.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 19, 2018, 11:09:45 am
content: Here is a contrasting design I knocked up. To send x"AAAAAA" out over the serial port, MSB first.Uses only one clock domain, and synchornizes the trigger pulse (which can be as short as a single clock cycle).Code:library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.NUMERIC_STD.ALL;entity maf_serialiser isPort ( clk : in STD_LOGIC;trigger : in STD_LOGIC;sclk : out STD_LOGIC := '1';sync : out STD_LOGIC := '1';sout : out STD_LOGIC := '1');end maf_serialiser;architecture Behavioral of maf_serialiser issignal clk_divide : unsigned(7 downto 0) := (others => '0');constant termincal_count : unsigned(7 downto 0) := to_unsigned(100-1,8);signal busy_sr: std_logic_vector(24 downto 0) := (others => '1');signal sync_sr: std_logic_vector(24 downto 0) := (others => '1');signal data_sr: std_logic_vector(24 downto 0) := (others => '1');signal trigger_sync : std_logic := '0';signal trigger_safe : std_logic := '0';signal phase : std_logic := '0';signal clk_enable : std_logic := '0';beginsync <= sync_sr(sync_sr'high);sout <= data_sr(data_sr'high);process(clk)beginif rising_edge(clk) then-- Transmit data in the shift registersif clk_enable = '1' thenif clk_enable = '1' thenif phase = '1' thenbusy_sr <= busy_sr(busy_sr'high-1 downto 0) & '0';data_sr <= data_sr(busy_sr'high-1 downto 0) & '1';sync_sr <= sync_sr(busy_sr'high-1 downto 0) & '1';sclk <= '0';phase <= '0';elsesclk <= '1';phase <= '1';end if;end if;end if;-- Are in a state that we can accept new data?if busy_sr(24) = '0' and trigger_safe = '1' then-- move the new data into the shift registersbusy_sr <= (others => '1');sync_sr(23 downto 0) <= (others => '0');data_sr(23 downto 0) <= x"AAAAAA";end if;-- Generate the clock enableif clk_divide = termincal_count thenclk_enable <= '1';clk_divide <= (others => '0');elseclk_enable <= '0';clk_divide <= clk_divide+1;end if;-- Synchronise triggertrigger_safe <= trigger_sync;trigger_sync <= trigger;end if;end process;end Behavioral;It is missing some ASYNC_REG attributes to make the best of the synchroniser.

author: Detzi
author_rank: Regular Contributor
timestamp: April 19, 2018, 12:25:35 pm
content: Thank you very much for spending your time and the effort done!Quote from: hamster_nz on April 19, 2018, 11:09:45 amYeah that true, i fixed that! Thanks!Quote from: hamster_nz on April 19, 2018, 11:09:45 amThe Trigger is actually working, its more like a debounce thing which generates a cmd signal that starts the sequence. I don't know why it is not working for you, it is for me.Quote from: hamster_nz on April 19, 2018, 11:09:45 amThe intention behind the 3 different clocks was that i need the Datapackets from the Sinetable transferred and updated with a frequency that corresponds to the desired output Sine, 2,08MHz is a bit too fast. The Second frequency was derived as i saw that my PISO seems to need two cmpclk cycles to update the output, the result was a 0101... instead of a 1100..... Therefore i wanted a ''SCK'' that is slower than the cmpclk.Quote from: hamster_nz on April 19, 2018, 11:09:45 amI triple checked all leads and connections, i also have checked that the PISO kinda works. If i push the KeyA (TasterA) it puts one sequence on the bus. I can see that sequence so i am definitly shure that i have labeled the Net correctly. So the distortion definitely occuring on the SCL-Pin respectively the clock signal comming out of PrescalerSCK. My Simulation is showing all signals fine with no errors. The reallity though proofs it wrong.There are some things i have changed in the meantime:- removed the file PescalerSCK and instead made a new instance of "Prescaler"-> no effect- i changed the sythesis tool inside of Diamond to "Synplify Pro"-> everything works great!so i guess it is some kind of degree of freedome for the synthesis tool to decide what it wants to do...but i don't see it. Because i do not need to start the PISO-Sequence in order to see the bursts i guess it won't be the initial values of the PISO, but i'll try anyway.Thank again for your effort!

author: Detzi
author_rank: Regular Contributor
timestamp: April 19, 2018, 12:34:31 pm
content: Quote from: hamster_nz on April 19, 2018, 11:09:45 amI want to be honest with you. I really don't know of which quality the code you provided is. Simply because i have no reference. But it seems to work, thats great

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 19, 2018, 01:57:31 pm
content: The Prescaler and PrescalerSCK entities do exactly the same thing, so you don't need to define the two. Just instantiate Prescaler twice. Entities can be instantiated as many times as you wish.Quick note: there is no need for first-level parentheses in 'if' clauses in VHDL, unlike C. VHDL is similar to Pascal derivatives syntax-wise and very close to ADA as a language.The serializer: as I got it, you're using an extra bit to test for the end of transmission instead of using a counter. Why not.The or_reduce() can be replaced with a simple comparison to 0.Code:if data_register(size downto 0)= 0 thenYou're clocking the serializer with compclk, shouldn't it be with sck_clk?I really don't like designs with no explicit reset signals. Signal initialization without explicit reset usually works on most FPGAs due to their internal structures, but would most likely fail on bare-metal targets such as ASICs, so I don't recommend doing this for portability reasons.Since you seem to have issues with sck_clk, have you tried removing everything in your top-level unit except the two prescalers and just output the clocks on IOs?

author: Detzi
author_rank: Regular Contributor
timestamp: April 19, 2018, 02:20:18 pm
content: Quote from: SiliconWizard on April 19, 2018, 01:57:31 pmQuote from: Detzi on April 19, 2018, 12:25:35 pmI already noticed that myself, but yeah that is much more convieniant.Quote from: SiliconWizard on April 19, 2018, 01:57:31 pmYou got it right. I tried to do something like that at the beginning, it was something with (others=> '0') statement but that didn't work. So i replaced it with the 'or_reduce'. But i will try yours as well seems to be a bit shorter.Quote from: SiliconWizard on April 19, 2018, 01:57:31 pmNow thinking you are probably right. In the end i could toss the faulte component out. But then i still would not know what went wrongQuote from: SiliconWizard on April 19, 2018, 01:57:31 pmYou again are right, i will implement resets in the future and try to let it get a habit.Quote from: SiliconWizard on April 19, 2018, 01:57:31 pmI did strip it to the internal OSC and the two prescalers. No difference in the Outputs.I really appreciate your effort! Thanks.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 19, 2018, 03:18:26 pm
content: Quote from: Detzi on April 19, 2018, 02:20:18 pmSo you mean that with a stripped down version of your design, the offending clock (sck_clk) still outputs what appears to be bursts of half frequency of compclk?

author: Detzi
author_rank: Regular Contributor
timestamp: April 19, 2018, 08:44:49 pm
content: Yes that is correct.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 19, 2018, 09:02:10 pm
content: Quote from: Detzi on April 19, 2018, 08:44:49 pmThat seems really odd. I still suspect that you have somehow got pins mixed up, as there is no way that your code can generate anything but a steady clock with 50% duty cycle.Simulate it if at all possible.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 19, 2018, 10:14:21 pm
content: Yeah, it's odd. I took a look at the .lpf file and there seems to be nothing odd with your pin attribution.If I get it right, you said you're having this odd problem when using LSE but not with Synplify?I have encountered a bug in LSE in the past but certainly not on something as trivial as a clock divider... so that's very odd. Have you tried updating Diamond? Your version is a bit dated.

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 05:43:00 am
content: Quote from: hamster_nz on April 19, 2018, 09:02:10 pmI simulated it already, and the simulation shows it fine. That i had Pins mixed up was one of my first ideas too, even before starting the Topic. So i removed all the probes and reconnected them triple checking the Pin assignment in the Spreadsheet against my Pobepoint and labels. The result was the same Signal. Against the "Mixed Up Testlead" theory is also the fakt that i can see the correctly prescaled clock when using "Syplifie Pro" as synthesis Tool.Quote from: SiliconWizard on April 19, 2018, 10:14:21 pmYes you get it right, using LSE -> bad ; using Synplify -> good.It moaned something like "there is a newer version" but i usualy try to avoide this kind of updates, they mostly do more harm than good. But now facing this kind of trouble one can argue to do the update, but i am still not happy with it. As you said, a simple clock divider should be possible with either version, shouldn't it?

author: ale500
author_rank: Frequent Contributor
timestamp: April 20, 2018, 05:45:33 am
content: QuoteNothing happens after recompile ?... there is something there: Clean generated files, if needed erase the implementation directory (be careful not to delete your source files!). And re-run the synthesizer: read all messages ! maybe there is something funny with your code. And yes, sometimes if you modify the source files externally (don't know if you did that), they seem to not trigger a full recompile.You can use the LEDs on the breakboard to show you a version number, that way you can be sure that you run your most recent code.Simulation alone is sadly not a proof that the "code" works on a real FPGA, but a strong indication.

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 07:30:14 am
content: Meanwhile i checked the NetlistViewer a bit more carfully and i think this proofs that the two instances are threated different(See attached Pictures).Quote from: ale500 on April 20, 2018, 05:45:33 amI'll run a cleanup and recompile, but i am quite shure that i got the right Version, i can change things by changing the Synthesis tool inside of Diamond so the file picked should be correct. But i'll try anyway.

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 07:44:29 am
content: Quote from: Detzi on April 20, 2018, 07:30:14 amSo shure enough when i hit "cleanup process" and "rerunn all" the netlist view changes to that what one would expect. Two absolutely same built components (Picture Attached). But regardless, the output is still crap and as before.I also attached my stripped Version of the Project.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 08:29:49 am
content: Quote from: Detzi on April 20, 2018, 05:43:00 amWell, I usually update my tools on a regular basis, but before I do, I take a look at the change log to figure out if this is worth it.Diamond 3.7 is a few minor versions behind, don't remember exactly but it may be 2 years old or something.Quote from: Detzi on April 20, 2018, 05:43:00 amYes. I have used version 3.7 and never ran into any issue that I can remember. (The bug I was mentioning was with EBR when using LSE with version 3.9)

author: hamster_nz
author_rank: Super Contributor
timestamp: April 20, 2018, 09:24:25 am
content: What is the frequency of the OSCH clock output? Is it 2.08MHz?Because that is what the design is constrained for...Edit: (Just looked at the screen shot, and that seems true).

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 11:32:42 am
content: Had a MachXO2 breakout board (1200ZE) lying in a drawer. So I checked (using Diamond 3.10). And I get exactly the same issue as you.I added a reset signal, in hope that could be a flip-flop reset problem. Didn't change anything.I compared the way LSE and Synplify synthesize this, and it's significantly different, but I don't get what's wrong yet. That's puzzling.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 03:07:53 pm
content: Ok, got it.First, you may notice that the "optimize for area" goal gives a correct behavior with LSE, but not the 2 others (balanced, timing). YMMV depending on your version I guess.This is a common issue with most FPGAs actually. Clocks generated this way tend to have excessive skew, particularly when using rather "big" counters (10 bits here). Excessive skew can lead to unwillingly creating several clock domains. Some synthesis tools are better than others at minimizing clock skew. And in this particular case, I would at least expect a warning from LSE - and we don't get any. That's bad.But the only guaranteed way of keeping several derived clocks synchronized is to use the FPGA's embedded clock resources. You can try forcing synthesis to behave with timing constraints, but that's often in vain. (I tried several constraints but to no avail in this case.) LSE does NOT automatically map these dividers to the appropriate clock resources.I usually use the embedded PLL(s) to generate several synchronized clocks in my designs. You may take a look at the PLL IP of the MachXO2. It's pretty flexible and guarantees clock synchronization.If you still want to implement dividers "manually", one thing you can do is to do as you would for signals coming from different clock domains: resynchronize the output of your dividers to the same source clock. Another way that works is to clock all your processes from the same clock, and use enable signals to make some processes run slower (once every N clock pulses). That would seem exactly the same, but it's not: when doing this, you don't have clock skew issues.

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 03:08:43 pm
content: Quote from: SiliconWizard on April 20, 2018, 11:32:42 amThanks man for fighting along with me. I have some minor update, changing the build strategy to "area" does fix it too.Quote from: hamster_nz on April 20, 2018, 09:24:25 amI measure 2.273MHz on the output. 2.08MHz is intentionally, i constrained it that way.Quote from: SiliconWizard on April 20, 2018, 08:29:49 amI like my tools consistent as long as there is no security issue i just don't bother updating anything as long as it works. Nethertheless I did update to the newest Version, did have no effect. Besides changing the list order of the "Export Files"

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 03:26:02 pm
content: Quote from: SiliconWizard on April 20, 2018, 03:07:53 pmSo if i get you right the fault, essentially is to genreate a clock not with normal logic becaus the skew and or delay can lead to unforseable behaviour.I thought a bit about that. So when generating the Clocks, in this case non shared, with normal logic shouldn't that just result in a delayed signal? Or is it likely that the synthesis tool couples the signals somehow together?

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 03:55:49 pm
content: There are specific clock distribution structures inside FPGAs to minimize skew. But when implementing dividers in this way, you have no guarantee the tools will/or can use those resources, so they will use general-purpose logic that are not made for clock distribution. There are flip-flops everywhere in FPGAs and clocks have specific requirements that other kinds of signals don't.I tried the two last methods I mentioned on your design and both worked.One thing to consider is that you often don't really need several (synchronized) clocks in a design. You can embed your prescalers inside the processes themselves and clock them all with just one clock.Cases where it would make sense to make them true clocks is if those clocks were distributed to a lot of modules in your design. If this is just for one serial communication block such as in your example, just embed the prescalers inside the processes and you won't have this kind of issues.

author: Detzi
author_rank: Regular Contributor
timestamp: April 20, 2018, 04:40:54 pm
content: To be honest i don't think i understand in depth but i understood that i am using the thing in a non intended way. Good thing to know! I am really grateful for your time and effort spend to solve my problem. Thank you!But now, i implemented a single PLL instead of the Dividers, as mentioned earlier the second divider is not needed at all so one PLL is enough. The Ouptput Frequency seems to be rather limited what means it is not as slow as i wanted it to be but regardless it puts out 800kHz and works. But now the Crap is coming out of my 'Sync' signal! It drives me f****** mad! Any Ideas?

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 06:14:11 pm
content: Quote from: Detzi on April 20, 2018, 04:40:54 pmYou 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.Quote from: Detzi on April 20, 2018, 04:40:54 pmNot 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:if(data_register(size-1 downto 0)=0) thenand later on this:Code:if (data_register(size downto 0)=0) thenI admit I got confused upon the first reading of this process.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2018, 07:06:19 pm
content: 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.

author: Detzi
author_rank: Regular Contributor
timestamp: April 21, 2018, 06:38:46 am
content: Quote from: SiliconWizard on April 20, 2018, 06:14:11 pmI 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_qicoBMOLtIi 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"?Quote from: SiliconWizard on April 20, 2018, 06:14:11 pmI 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.Quote from: SiliconWizard on April 20, 2018, 07:06:19 pmI 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!

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 21, 2018, 03:51:42 pm
content: Quote from: Detzi on April 21, 2018, 06:38:46 amWell, 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.Quote from: Detzi on April 21, 2018, 06:38:46 amNope. 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.Quote from: Detzi on April 21, 2018, 06:38:46 amThere'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=45588For VHDL, although it shouldn't be your only source, the Free Range VHDL book is free and well regarded.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 21, 2018, 08:27:57 pm
content: 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.

author: Detzi
author_rank: Regular Contributor
timestamp: April 23, 2018, 08:52:00 am
content: Quote from: SiliconWizard on April 21, 2018, 08:27:57 pmThat is really kind of you i will have a look at it soon.Quote from: SiliconWizard on April 21, 2018, 03:51:42 pmI 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.Quote from: Detzi on April 21, 2018, 06:38:46 amSo it was no contact issues it was picked up noise, most likely from the nearby clock lead...lesson learned the hard way.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 23, 2018, 01:54:25 pm
content: Quote from: Detzi on April 23, 2018, 08:52:00 amWell, 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.Quote from: Detzi on April 21, 2018, 06:38:46 amTo 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.