UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant alexium
Participant
8,794 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

 


@eteam00 wrote:

You have more problems in your code than you realise.  The absolute killer (async input) is #4 in the list below.

 

1.  You treat rx_countdown as a 4-state (actually, 5-state) counter (you divide the bit period into 4 phases).  But rx_countdown is a 6-bit register?

 

2.  There are conflicting (overlapping) assignment statements within the same process for rx_clk_divider and rx_countdown.  No no no no no NO.

 

3.  What's with assigning register values inside a clocked process with blocking (rather than non-blocking) assignment statements?  NO!

 

4.  state RX_CHECK_START -- the odds of 8-bit register recv_state being 'updated' non-uniformly due to skews of aynchronous rx input, using a 100MHz clock, are excellent.  If skews for rx input cover a 1nS range, a 100MHz clock (10nS clock period) will result in a corrupted state machine at least 10 times (characters) out of 100.  If the rx skews are greater than 1nS, the odds of state machine corruption are even higher.

 

5.  The comment about the clk_divider counter is incorrect.  Corrected below.

// Whenever it reaches 0, 1/16 1/4 of the bit period has elapsed.

6.  The receive states are defined as 7-bit parameter values, yet the recv_state register is 8 bits.  You are assigning 7-bit values to an 8-bit register.  You are also comparing this 8-bit register to 7-bit values.

 

I didn't review the TX state machine.  This should be enough to keep you busy.

 

-- Bob Elkind


 

1, 6. Is it a problem? I thought XST will just trim unused most significant bits...

2. Is it a problem? I don't like such a style, and try to avoid it, but I was told it is OK and synthesis tool will synthesize this correctly (i.e. at every clock edge only the last assignment will take effect).

3. Ouch! I thought "=" is non-blocking and "<=" is blocking... Now you you know why I prefer VHDL. But it will only make a difference in simulation, right?

4. Now's the most interesting part.  I totally don't get it. Firstly, I to find out what a skew is, and it seems to me that signal's edge position variance on a timeline from period to period is called a skew. Do you mean rx signal might bounce? But we are sampling it 1/4th period away from edge, which is a HUGE amount of time since UART is very slow... I have a feeling you were saying something else, please explain.

 

In my defence I can only say it's not my code, it's from OpenCores.org :) And it's the best of UART's present there. Some others I've tried didn't even work in the test project, and the code of this UART is the clearest among what  I saw...

 

0 Kudos
Instructor
Instructor
8,788 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

4.  state RX_CHECK_START RX_IDLE -- the odds of 8-bit register recv_state being 'updated' non-uniformly due to skews of aynchronous rx input, using a 100MHz clock, are excellent.  If skews for rx input cover a 1nS range, a 100MHz clock (10nS clock period) will result in a corrupted state machine at least 10 times (characters) out of 100.  If the rx skews are greater than 1nS, the odds of state machine corruption are even higher.

4. Now's the most interesting part.  I totally don't get it. Firstly, I to find out what a skew is, and it seems to me that signal's edge position variance on a timeline from period to period is called a skew. Do you mean rx signal might bounce?

Assumptions:

  • 100MHz clock -- 10nS clock period
  • 8-bit state register, value dependent on async input RX
  • Prop delay from async RX input to STATE[0] bit = 2nS (modulo 10nS)
  • Prop delay from async RX input to STATE[7] bit = 4nS (modulo 10nS)
  • setup and hold time for STATE register is 0nS (just for the sake of discussion)

If RX input propagates to STATE[0] register just after the clock edge, and RX input will arrive at STATE[7] register 2nS later (the difference in RX prop delay to the two different register bits), then both STATE[0] and STATE[7] will be updated on the next clock edge based on the same value of RX.  We'll call this timing relationship T=0 (RX arriving at STATE[0] 0 nS after clock rising edge).


If RX input propagates to STATE[0] register 8nS after the clock edge, then RX input propagates to STATE[7] register just at clock rising edge, and both register bits will be updated on the same clock edge based on the same value of RX.  This timing is T=(-2), or T=8.

 

If RX input propagates to STATE[0] register 9nS after the clock edge, then RX input propagates to STATE[7] register 1nS after the clock rising edge. STATE[0] register bit will be updated on one clock edge and STATE[7] register bit will update on the following clock edge.  We'll call this timing T=9.


For timing T=0 to T=8, STATE[0] and STATE[7] will update on the same clock edge based on the same value of RX input.


For timing T=8 to T=10 (a timing window which is 2nS wide), RX input will propagate to STATE[0] register input before one clock edge and RX input will propagate to the STATE[7] register input after the same clock edge.  STATE[0] and STATE[7] will update on different clock edges -- different clock cycles.  After the first clock edge the STATE register will be corrupted and incoherent.

 

Out of a 10nS clock period, 20% of the time (2ns out of 10nS clock period) the RX input state change will arrive at a time which will result in corruption of the STATE register.

But we are sampling it 1/4th period away from edge, which is a HUGE amount of time since UART is very slow... I have a feeling you were saying something else, please explain.

This is not the case in your state machine state RX_IDLE.  (note that I originally cut/pasted RX_CHECK_START which is incorrect -- I will update/correct my last post)


-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Instructor
Instructor
8,780 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

1, 6. Is it a problem? I thought XST will just trim unused most significant bits...

The 'extra' bits are not unused.  At least I don't think so.  When you (or someone else) need to revisit your code a year or two from now, or you port your design to another synthesiser, would you like the 'intent' of your design to be clear, or would you like it to be ambiguous?

2. Is it a problem? I don't like such a style, and try to avoid it, but I was told it is OK and synthesis tool will synthesize this correctly (i.e. at every clock edge only the last assignment will take effect).

What stops you from implementing a clean and unambiguous design?  Especially if your design isn't working as expected or as simulated, what justification might you have for making room for uncertain synthesis?

3. Ouch! I thought "=" is non-blocking and "<=" is blocking... Now you you know why I prefer VHDL. But it will only make a difference in simulation, right?

I can't believe you wrote that.  I'm sure your better judgment will take hold on your next reading.

 

There is so much detail in each design, and so much which depends on design success.  Please learn discipline and rigour in your design... both for your sake and the sake of your future business associates who depend on your work for their livelihood.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Participant alexium
Participant
8,772 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution
Is my understanding correct that putting RX signal through an FF makes it impossible (well, not impossible, but unlikely) for RX to change just before the clock edge, making sure any change will only occur strictly between the edges?
0 Kudos
Participant alexium
Participant
8,770 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

 


@eteam00 wrote:

1, 6. Is it a problem? I thought XST will just trim unused most significant bits...

The 'extra' bits are not unused.  At least I don't think so.


 

I was wrong, you're right. I didn't get a warning about that, and I shaved few LUTs off by setting the proper register size.

 


@eteam00 wrote:

2. Is it a problem? I don't like such a style, and try to avoid it, but I was told it is OK and synthesis tool will synthesize this correctly (i.e. at every clock edge only the last assignment will take effect).

 what justification might you have for making room for uncertain synthesis?



 None. Of course, none. But sometimes such a technique really makes code smaller and easier to grasp (not in this case, though).

 

 


eteam00 wrote:

3. Ouch! I thought "=" is non-blocking and "<=" is blocking... Now you you know why I prefer VHDL. But it will only make a difference in simulation, right?

I can't believe you wrote that.  I'm sure your better judgment will take hold on your next reading.

 

 


 

I can't believe what I said is not true! I'm already blowing dust off my Verilog book as we speak.I decided to swap all blocking assignments with non-blocking, but that broken the device. No more Verilog modifications before reading the book, I guess :)

 

I can't stress enough how helpful you've been. You have saved my design from my tutor!

Thank you!

0 Kudos
Instructor
Instructor
8,769 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

Is my understanding correct that putting RX signal through an FF makes it impossible (well, not impossible, but unlikely) for RX to change just before the clock edge, making sure any change will only occur strictly between the edges?

When synchronising the asynchronous input, the synchroniser FF output conforms to the same timing rules and assumptions as the rest of your single-clock logic design.  As long as prop delay from sync FF output to destination register inputs meets data-to-clock setup time, all is well.

 

A single synchroniser FF reduces likelihood of metastable states considerably.  Two successive FFs take metastable possibility down to nonexistent, for all practical purposes.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Participant alexium
Participant
8,764 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution
Understood.
0 Kudos
Instructor
Instructor
8,762 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

what justification might you have for making room for uncertain synthesis?

But sometimes such a technique really makes code smaller and easier to grasp (not in this case, though).

So uncertainty == easier to grasp?

I vaguely remember your having concerns about inscrutable FSM coding style.  You haven't been turned to 'the dark side', have you ?

3. Ouch! I thought "=" is non-blocking and "<=" is blocking... Now you you know why I prefer VHDL. But it will only make a difference in simulation, right?

 

I can't believe you wrote that.  I'm sure your better judgment will take hold on your next reading.

 

I can't believe what I said is not true!

Alexium...  would you agree that a simulation model which accurately reflects the actual hardware is ... essential?  The very idea of using a coding style which causes simulation to diverge from hardware accuracy should make you poop your pants (that's a technical term, cleaned up for family viewing).

I decided to swap all blocking assignments with non-blocking, but that broken the device.

Sounds like you've proven that using blocking vs. non-blocking assignments is important.

 

Note 1:  in the future, change only one process or module at a time.  This makes debugging considerably simpler -- you can focus on small set of code for debugging.

 

Note 2:  As long as you're re-coding and debugging, maybe you want to clean up the overlapping register assignments within a single process.  You may find that this will help 'un-break' the 'damage' caused by replacing blocking assignments with non-blocking assignments.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Participant alexium
Participant
8,746 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

 


@eteam00 wrote:
But sometimes such a technique really makes code smaller and easier to grasp (not in this case, though).

So uncertainty == easier to grasp?

I vaguely remember your having concerns about inscrutable FSM coding style.  You haven't been turned to 'the dark side', have you ?

 

 


 

No I haven't : ) I'm not justifying the coding style of this particular module, I'm just saying that sometimes it might be a  valid choice to use overlapping assignments. In fact, Xilinx ISE's language templates use overlapping assignments, both for combinatorial and sequential logic (Can't find Verilog example, but I know VHDL examples to back up my statement).

 

 


@eteam00 wrote:

 would you agree that a simulation model which reflects the actual hardware accurately is ... essential?  The very idea of using a coding style which causes simulation to diverge from accuracy should make you poop your pants (that's a technical term, cleaned up for family viewing).


Yes, I have no choice but to agree.

 

 


@eteam00 wrote:

Sounds like you've proven that using blocking vs. non-blocking assignments is important.

 

 


 

Sounds like I did.

Now I'm starting to understand it was irrational to assume that blocking and non-blocking assignments behave  equally in hardware, because in that case simulation would not reflect the behaviour in HW. I see your point now.

0 Kudos
Participant alexium
Participant
8,745 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

 


eteam00 wrote:

Note 2:  As long as you're re-coding and debugging, maybe you want to clean up the overlapping register assignments within a single process.  You may find that this will help 'un-break' the 'damage' caused by replacing blocking assignments with non-blocking assignments.

 


Interesting... I'll try to do that. I wonder if it will change circuit's charasteristics significantly (LUT usage / max. frequency).

 

0 Kudos
Instructor
Instructor
8,920 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

In fact, Xilinx ISE's language templates use overlapping assignments, both for combinatorial and sequential logic (Can't find Verilog example, but I know VHDL examples to back up my statement).

This troubles me.  If you can point out specific examples, I'd like to learn more.

Thanks for the heads up!

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Participant alexium
Participant
8,916 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

Sure!

From the top of my head - VHDL FSM template uses overlapping statements for combinatorial process:

 

 

 NEXT_STATE_DECODE: process (state, <input1>, <input2>, ...)
   begin
      --declare default state for next_state to avoid latches
      next_state <= state;  --default is to stay in current state
      --insert statements to decode next_state
      --below is a simple example
      case (state) is
         when st1_<name> =>
            if <input_1> = '1' then
               next_state <= st2_<name>;
            end if;
         when st2_<name> =>
            if <input_2> = '1' then
               next_state <= st3_<name>;
            end if;
         when st3_<name> =>
            next_state <= st1_<name>;
         when others =>
            next_state <= st1_<name>;
      end case;      
   end process;

 And that's what I meant by saying this technique might simplify things: otherwise you would have to write else for every present if .

 

0 Kudos
Instructor
Instructor
8,908 Views
Registered: ‎07-21-2009

Re: incomplete code review

Jump to solution

The example you quote is only for the NEXT_STATE_DECODE template example, where the process is combinatorial instead of clocked.  This is a classic two-process state machine, separating combinatorial assignments from sequential clocked assignments.

 

Note that all of the Verilog state machine template examples are single-process (clocked) only.  There is no need for overlapping assignments, nor is there need for else statements to retain current state.

 

As far as I'm concerned, the default state register assignment in these VHDL template examples (next_state <= current_state) is less odious than the multiple counter assignments in your original code.

 

How is the conversion and debugging going?

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Participant alexium
Participant
8,905 Views
Registered: ‎04-22-2010

Re: incomplete code review

Jump to solution

 


@eteam00 wrote:

The example you quote is only for the NEXT_STATE_DECODE template example, where the process is combinatorial instead of clocked.  This is a classic two-process state machine, separating combinatorial assignments from sequential clocked assignments.

 

 


 

Actually, VHDL FSM template has 3 processes, I've only posted one that has overlapping assignments.

And I don't quite understand why they suggest 3 for VHDL but one for Verilog (considering one-process VHDL FSMs have never failed me).

 

 


@eteam00 wrote:

 

 

As far as I'm concerned, the default state register assignment in these VHDL template examples (next_state <= current_state) is less odious than the multiple counter assignments in your original code.

 


Absolutely! I have absolutely, no idea why the autor of the code designed it that way, I certainly wouldn't do so.

 

 


@eteam00 wrote:

 

 

How is the conversion and debugging going?

 

 


 

As for debugging - I'm enjoying the project's stability with all options enabled that broke the design before. Feels great!

As for conversion - I took several hours off, have just begun looking at the code and scratching my head before touching anything : )

0 Kudos
Teacher eilert
Teacher
8,886 Views
Registered: ‎08-14-2007

Re: FSM's - why and their synthesis?

Jump to solution

The reports of my absence are greatly exaggerated! :smileyhappy:

 

Hi Bob,

actually the link to my account you posted is a little outdated.

This is the true link to  my account:

http://forums.xilinx.com/t5/user/viewprofilepage/user-id/127

 

Some latency in responing is mostly due to weekends and living in another time zone.

 

Regards

  Eilert

 

 

 

 

0 Kudos
Teacher eilert
Teacher
8,884 Views
Registered: ‎08-14-2007

Re: FSM's - why and their synthesis?

Jump to solution

Hi,

there has already been some long discussion over the weekend, but I'd like to explain my statement directly.

 

The proposal was directed to someone who had trouble with the readability and synthesis of some FSM.

This often is caused by mixing too much stuff into some process without having the experience to estimate the outcome.

 

If someone has enough experience and everything works fine, then almost any style and method is OK.

 

Some example I have observed some years ago may be helpful to understand:

In a FSM some student wanted to increment a counting value in (almost) each state.

The result was a gruesome large FSM, because he ended up with a plethora of adders, one in each state (instead of the desired single one needed for counting).

This might have been a tool issue then, or a coding issue, who knows...

Still, the solution was to create a separate counter and just create a count enable signal by the FSM.

 

So this was just some simple case. Imagine what could happen when someone tries to integrate some complex datapath into his FSM and ends up in a mess.

Separating FSM and datapath also means being able to separate debuging and testing of these modules. 

 

In the end it's all mostly a question of personal preferences and abilities.

But those who are in trouble need some advice that eases up their problem.

 

Have a nice synthesis

  Eilert

 

Participant alexium
Participant
8,881 Views
Registered: ‎04-22-2010

Re: FSM's - why and their synthesis?

Jump to solution

Grretings,  Eilert!

Looks like I was right after all :)

 

Thanks for clarifying that advice regarding FSM coding!

So, as far as I understand, the consensus is as follows: any coding style is good whilst it produces the desired result and remains readable.

 

Alex

0 Kudos
Instructor
Instructor
8,805 Views
Registered: ‎07-21-2009

Re: FSM's - why and their synthesis?

Jump to solution

The reports of my absence are greatly exaggerated! :smileyhappy:

In honour of eilert's resurrection return, I offer this bit of celebration...  Enjoy!

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Historian
Historian
8,764 Views
Registered: ‎02-25-2008

Re: FSM's - why and their synthesis?

Jump to solution

 


@alexium wrote:

 

I do use a style that is logical to me, but there is a problem: my code misbehaves in hardware, and my tutor told me  synthesis tool didn't synthesise my FSM properly  because I didn't stick with 3-process FSM template and because I didn't separate the datapath from the FSM. I seriously doubt my tutor is right, but I'd rather ask someone experienced. All in all, I have no other ideas as to why doesn't my code work...

 


Please, kill him. He's a fscking moron.

 

----------------------------Yes, I do this for a living.
0 Kudos
Historian
Historian
8,761 Views
Registered: ‎02-25-2008

Re: incomplete code review

Jump to solution

 


@alexium wrote:

 

Actually, VHDL FSM template has 3 processes, I've only posted one that has overlapping assignments.

And I don't quite understand why they suggest 3 for VHDL but one for Verilog (considering one-process VHDL FSMs have never failed me).


Back in the bad old days, before synthesis tools were any good, they (meaning it, where it was the horrific Synopsys FPGA Express) required you to separate the state update logic from the register logic. And as such documentation was written with examples to reflect this lossage.
Now that we have modern tools that do a fabulous job of correctly inferring FSMs from a single synchronous process, the multiple-process style should be avoided unless you have a significantly-compelling reason to use it.
If you have an instructor saying that your code isn't working because you didn't conform to the obsolete three (!)-process state machine template, then he's an idiot and should not be teaching.
Xilinx rarely updates their examples, which is why they still recommend the obsolete styles and obsolete libraries (std_logic_arith, etc) even as the world has moved on.

 

----------------------------Yes, I do this for a living.
Instructor
Instructor
2,699 Views
Registered: ‎07-21-2009

Re: FSM's - why and their synthesis?

Jump to solution

Please, kill him. He's a fscking moron.

Alexium, if you are reluctant to follow bassman's advice, perhaps you should send bassman a plane ticket to your location.  I'm sure bassman will be happy to perform this service for you.

 

-- Bob Elkind (yes, I am kidding)

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Participant alexium
Participant
2,681 Views
Registered: ‎04-22-2010

Re: FSM's - why and their synthesis?

Jump to solution

Ha-ha, I went away for a few days - and I almost missed the best part of the discussion :)

 

bassman59, thanks for explaining that. In defence of my tutor I'd like to say he only started diving into the field of HDL and synthesis recently, and he's still learning. And believe me, he is a professional. It's just... Well, you can't know everything, can you?..

 

 


@eteam00 wrote:

yes, I am kidding


  Oh, good thing you didn't forget to mention!

BTW, I seem to grasp the difference between blocking and non-blocking assignments in Verilog :)

 

0 Kudos