element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
FPGA
  • Technologies
  • More
FPGA
Forum Connecting Verilog to Synthesis
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join FPGA to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Verified Answer
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 546 subscribers
  • Views 2858 views
  • Users 0 members are here
Related

Connecting Verilog to Synthesis

mraureliusr
mraureliusr over 11 years ago

Hey everyone! Wish I had seen this group earlier.

 

I'm hoping there's a few here who are familiar with the Xilinx ISE. I'm finally making a concerted effort to learn Verilog and this time around I'm doing well. I'm grasping the language concepts well, and am enjoying the book I picked up from the local University library (public library is a bit short on HDL books!) called "Verilog for Digital Design" written by Frank Vahid and Roman Lysecky. Make sure to check for the 2002 edition, there are older versions as well. This book is the perfect blend of theory and practical code writing.

 

Anyway, I wanted to try implementing a simple design of my own, essentially recreating the functionality of four 74193 up/down binary counters. The inputs are four buttons, up, down, load and store. The load and store buttons control signals for a later stage of the design.

 

I wrote the counter module, then created a top level module and instantiated the     counter module. I simulated it with a simple test bench and it worked!! Amazing!

 

However, now I'm trying to implement it in my Spartan-3E FPGA and I'm having trouble figuring out the hierarchy of a typical design. Clearly the top level module interfaces with the actual pins, and then passes these states to the instantiated module. But how do I pick which pins connect to the top level module? I see that PlanAhead seems to implement this stage of the design but I'm confused on how to put it all together. I'm also having trouble connecting the counter module ports to the top level module. It keeps giving me errors for the output bus, saying something like it's not a proper lvalue? The counter module has the counter output declared as an output reg[15:0] ... is that incorrect? The top level module also has the actual output declared as an output reg, is it improper to commect these types together? I figured within the counter module that the output should be a reg ad not a wire, because it needs to hold its value. Plus the output needs to be manipulated directly and it seems a reg was the easiest way to do this


Perhaps these questions will be answered later in the book but the ISE/Xilinx specific problems won't be addressed as the author uses different software and never directly talks about specific brands. He does focus on both simulation and synthesis though, which is what I was looking for. Most books on Verilog place a heavy focus on simulation, and while I've discovered how useful simulation is, I have this Xilinx dev board that I want to play/learn with!


Thanks everyone for reading all that. image Will be happy to share more as I learn more. If it helps I can post my code here.

  • Sign in to reply
  • Cancel

Top Replies

  • johnbeetem
    johnbeetem over 11 years ago +1 suggested
    I've never used PlanAhead. I always use a User Constraint File (.ucf) to define the pinout. The easiest way is to start with a working .ucf as a template, and then modify it. For example, here is the UCF…
Parents
  • mraureliusr
    0 mraureliusr over 11 years ago

    Dear God, this is driving me insane.

     

    John -- your advice is excellent! Thanks for the tips. I'm trying to implement your suggestion but I keep getting the same error:

    The logic for <count_Out> does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.

     

    ARGH!!! I really do not understand what I'm doing wrong. I'm having a hard time wrapping my head around certain concepts. Here's the block it's having trouble with. I want to note that I've tried implementing this a few different ways, for example creating an 'internal' clock that gets flipped on the negedge of b_Up, b_Down, Rst, and then having a separate always block for that 'internal' clock to handle the actual changes to count_Out. This made sense to me, but apparently not to XST. Clearly I'm doing something wrong...

    Anyway, here's what I'm back to now: (I've modified the ports to have the inputs/outputs declared afterward, though I think that's just a style choice as it's never caused any problems)

     

    module counter16(Clk, b_Up, b_Down, Rst, count_Out);

      input Clk, b_Up, b_Down, Rst;

      output reg[15:0] count_Out;

     

    always @(negedge b_Up or negedge b_Down or negedge Rst) begin

      if(Rst == 0) begin

      count_Out <= 16'h0000;

      end else begin

      count_Out <= count_Out + b_Up - b_Down;

      end

    end

    endmodule

     

    (EDIT: I've also used just if(!Rst) begin ... doesn't seem to make any difference, and I suspect !Rst is proper)

    I mean, what could be simpler? On the falling edge of any of those three signals, do that very simple thing. That's it! But apparently count_Out[15:0] <= 16'h0000; does not match a known flip flop or latch template.............. WHAT? Isn't that the whole point of Verilog, that you can describe circuits that don't use templates all the time? Man, this one has my head spinning. I think I should ignore what the error actually means and just try and figure out how to fix it. I've read and re-read the chapters that deal with the above concepts, but I don't see what I'm doing wrong....

     

    Sorry to burden you all with my problems, hopefully I'm not too much of a pain! image In a lot of ways, Verilog is a lot easier than I thought (though I won't say it's easy!!). However, it's the little syntactical things (like with any language) that really get me at first. Once you learn it, it's all second nature, which is how I am with C now that I've used it for so long. But this is taking a bit longer to sink in than I would have liked.

     

    Even if you can't describe the problem, perhaps you can just give me a few keywords to search and I can Google/check the index of the multiple Verilog books I currently have to see if the concept is covered well. I'm understanding the difference between structural and behavioural code well, but the difference between behavioural and combinational is escaping me, and I have a feeling this is at the root of my above errors.

     

    Thanks again for your patience everyone. Soon enough hopefully I'll be answering the newbie questions!

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • johnbeetem
    0 johnbeetem over 11 years ago in reply to mraureliusr

    Alexander Rowsell wrote:

     

    Anyway, here's what I'm back to now: (I've modified the ports to have the inputs/outputs declared afterward, though I think that's just a style choice as it's never caused any problems)

     

    module counter16(Clk, b_Up, b_Down, Rst, count_Out);

      input Clk, b_Up, b_Down, Rst;

      output reg[15:0] count_Out;

     

    always @(negedge b_Up or negedge b_Down or negedge Rst) begin

      if(Rst == 0) begin

      count_Out <= 16'h0000;

      end else begin

      count_Out <= count_Out + b_Up - b_Down;

      end

    end

    endmodule

     

    I think the problem is that XST wants each register to have a single clock.  It doesn't know what to do with multiple clocks, since if you look at the Xilinx cell structure each FF has only one clock.

     

    So you need something like:

     

    always @(posedge Clk or negedge Rst) begin

      if(Rst == 0) begin  // If Rst = 0, asynchronously reset count_Out.

      count_Out <= 16'h0000;

      end else begin  // If Rst = 1, update count_Out on the rising edge of Clk.

      count_Out <= count_Out + b_Up - b_Down;

      end

     

    When you use counter16, connect Clk to a fixed clock source.  Connect b_Up and b_Down to combinational inputs.  Alternatively, you can create logic that detects changes to b_Up and b_Down to create clock pulses, but this gets into asynchronous sequential logic which is not usually what you want to do with FPGAs.  FPGAs work best with a single clock that is distributed throughout the chip, with all combinational inputs synchronized to that clock so they have clean inputs and don't cause metastability.  This is particularly true with push-button inputs, which usually need to be debounced. 

     

    Regarding Verilog in general:  If I remember my history correctly, Verilog began as a language for producing test vectors and expected results for testing ICs.  Using Verilog as a synthesis language came later.  If you don't know how XST or other synthesizers work, it's easy to write Verilog that simulates fine but can't be synthesized.  I restrict myself to a subset of Verilog that works for the way I do design.  I don't know a reference book for this -- I have the advantage that I came to FPGAs from an electronic computer-aided design background, so I already had a good idea of what was possible and practical, and then added experience.

     

    Marketing would like you to think that you can write any Verilog you like and XST will magically create a wonderful FPGA.  This has not been my experience.  You must copy the templates carefully.  As I think I said above, my approach is to visualize the logic I want to produce, and then write the Verilog accordingly.  This creates the overall register-transfer structure.  XST does a great job of logic minimization given this structure.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • mraureliusr
    0 mraureliusr over 11 years ago in reply to johnbeetem

    Okay, thanks again John -- that helped clarify a few things. The book I'm reading emphasizes the difference between synthesizable and simulatable code quite strongly, so I understand that many things can't be synthesized. I just wasn't understanding that each always statement usually expects just one clock and an async reset.

    The problem is, if I make the block always @(posedge Clk) then any time you push the button it counts up hundreds of thousands of times in the space of milliseconds -- I just want it to increment once for each push. I was looking at the switches and yes, they do have some bounce on them, which is a pain but I'm going to be using debounced switches in the final design.

    I was thinking of doing what you mentioned, creating an artificial clock pulse from the buttons and then feeding that to the module. I guess this has to be done outside of the module (otherwise it doesn't synthesize for me), and that makes sense.

     

    Thank you so much for your advice! I'm going to keep at it and see what happens.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • johnbeetem
    0 johnbeetem over 11 years ago in reply to mraureliusr

    Alexander Rowsell wrote:

     

    The problem is, if I make the block always @(posedge Clk) then any time you push the button it counts up hundreds of thousands of times in the space of milliseconds -- I just want it to increment once for each push. I was looking at the switches and yes, they do have some bounce on them, which is a pain but I'm going to be using debounced switches in the final design.

    One way to handle the Up and Down inputs is to sample them every 10 msec or so and compare the new sample to the previous sample, which you stored in a flip-flop.  If the new value is ON and the old value is OFF, then update your 16-bit counter.

     

    Yes, you need a lot of counter bits to take your master clock (typically 30 MHz on most dev boards) down to 100 Hz, but in a serious design you often need those lower-frequency clocks for activity LEDs and other human-speed I/O.  Now when I say "lower-frequency clock", I really mean a low-duty-cycle logic signal clocked by the master clock.  The logic signal enables register updates, also clocked by the same master clock.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • mraureliusr
    0 mraureliusr over 11 years ago in reply to johnbeetem

    Yeah, my dev board has a 50MHz clock, so it was just screaming along.

    I noticed in the 'Core Generator' they have simple building blocks, such as a binary counter of arbitrary width, however it generates gate-level code which I can't really decipher yet.

     

    It'd be awesome if it generated Verilog. Also, your suggestion of checking out the code templates has been really, really handy. I'm super excited to keep learning more, whichever is a good sign --mwhen I was; earning assembly, running into problems would just frustrate me and I'd get discouraged and stop working at it. However, (mostly because you've been around to point me in the right direction) I've been having a good time learning, which is super important for me.

     

    I've been thinking about doing a short video series on getting started with Xilinx ISE & Basic Verilog. There's a lot of good electronics resources on YouTube but almost nothing good on FPGAs.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • johnbeetem
    0 johnbeetem over 11 years ago in reply to mraureliusr

    Alexander Rowsell wrote:

     

    I've been thinking about doing a short video series on getting started with Xilinx ISE & Basic Verilog. There's a lot of good electronics resources on YouTube but almost nothing good on FPGAs.

    Gadget Factory has some FPGA tutorials: http://gadgetfactory.net/learn/

     

    I've never looked at them myself, but I've seen positive comments in the Gadget Factory forum.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • johnbeetem
    0 johnbeetem over 11 years ago in reply to mraureliusr

    Alexander Rowsell wrote:

     

    I've been thinking about doing a short video series on getting started with Xilinx ISE & Basic Verilog. There's a lot of good electronics resources on YouTube but almost nothing good on FPGAs.

    Gadget Factory has some FPGA tutorials: http://gadgetfactory.net/learn/

     

    I've never looked at them myself, but I've seen positive comments in the Gadget Factory forum.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube