• Content count

  • Joined

  • Last visited

  • Days Won


zygot last won the day on January 16

zygot had the most liked content!

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

2565 profile views
  1. Vivado License on Cmod A7: Breadboardable Artix-7 FPGA Module

    @CleverDigitalGuy, I wasn't intending to berate you. You are not alone and there are frequent posts to the wrong forum. @JColvin Is there any easy way direct newcomers to the correct forum or for non-administrators to mark posts that should be somewhere else to assist in organization? I'm going to stop commenting. Finding pertinent answers to user's questions isn't easy; especially for older posts.
  2. FIFO CDC and Gray codes

    Yeah I have a small cache of SNUG articles from the past. The author uses the convention asynchronous to apply to 2 clock FIFOs which is not how I generally use the term to apply to logic. But as long as you state up front what you mean it's all good. The article isn't targeted to any particular architecture or technology and I'm not sure how much of it applies to the Xilinx Series 7 devices using Vivado. Still, the basic ideas, from an informational perspective, are good and lays out a number of concepts worth spending time to think about. Right or wrong, here are my feelings toward grey coded counters. If they are incremented ( counting by 1 ) or decremented (counting by 1 ) then there will only be a change in 1 bit of the count word. That's pretty much it. The author, like most people who've espoused the necessity of grey coding glosses over the details as to how they improve reliability for FPGAs running a particular bitstream. What the grey code absolutely can do is provide a mechanism for detecting multi-bit changes when single bit changes are expected. If you add the logic to do this and don't add the functionality to do something with that detected error than what have you accomplished? A FIFO certainly has pointers (likely counters that count up or count up and down by 1 ) so grey-coded counters are certainly appropriate. Is there a difference between a 16-deep FIFO and a 1 Mword deep FIFO? For sure as you will need quite a few BRAMS to implement the very deep one. There are other coding schemes for particular purposes. Personally, I'd never try to design my own 2 clock FIFO when I have the flawed but documented Xilinx IP or hard FIFO available. Regardless of how you handle it clock domains present the possibility of metastability. Now what I might want to do is create a large dual clock 2-port BRAM circular buffer because none of the FPGA vendors offer such a beast. I've played along these lines but wouldn't want to publish anything to date. I could use a well designed circular buffer. It should be easier than a FIFO, I think....
  3. Feedback on a register file design?

    There are a lot of things that you can do and not have problems for any given entity... if you fully understand what you are doing. There are hours or days of debugging ahead for those who don't when all of a sudden what seemed to be good practice for one project doesn't work out so well on another. Especially when entities become components in large hierarchical designs. More advice that you should feel free to ignore. I spent the first couple of years restricting my HDL to basic constructs and still had plenty of surprises to learn about. As time wore on I became more adventurous. Not everyone need operate this way... but probably more than do. You will, no doubt , find a coding style that suits the way that you work. Using individual operators from libraries would probably not work out for me as it does Piasa.
  4. Feedback on a register file design?

    @xc6lx45, You must like experimenting with the reaction of Africanized bee colonies to jack-hammers. I'm in a feisty mood today so what the heck... There is absolutely a place for hard CPU core based FPGA devices like the Zynq. I don't even feel the needs to support that statement. For almost all low power applications the FPGA can't compete with a commercial uC or DSP. I tend to be more sympathetic with you on soft CPU cores using FPGA resources. The exception is when you are pursuing a project that is a labour of love. Implementing a full-stack Ethernet interface in HDL makes no sense to me. There are times when post configuration programmability might push me toward a soft processor. But then I'd use an Atmel clone that someone else's software toolchain. If someone ( I can think of someone ) makes a great soft processor that is compatible with the gcc toolchain I might be interested. By and large HDLs get almost everything done that needs to be done. BTW there's thread in another section in the Digilent forum dedicated to just this topic... which would be a better place to post your argument.
  5. Feedback on a register file design?

    I might go with the notion that STD_LOGIC_VECTOR is a bucket of ULOGIC bits. I've done a lot of signed and unsigned VHDL projects and I can't say that I can't support the quote above. In C abstraction is a concept to be embraced. In logic design you are responsible for any abstraction you want to imply. VHDL, like ADA is a strongly typed language and will give you lots of error messages. You can still get into trouble, even with VHDL, especially with carries, overflow, comparison etc. Now that you've brought it up The ':=' implies instantaneous value assignment. It is not the same as the "<=" gets assignment. The two are not interchangeable. Confusing the two will result in "you := are_in_trouble" in a hurry. I rarely use ":=" except for simulation and special circumstances. You should understand that VHDL was not designed for synthesis. IT is a simulation language. Most, but not all of its statements can be synthesized into logic or are supported by vendors synthesis tools. Both Altera and Xilinx will tell you what statements are supported.
  6. Vivado License on Cmod A7: Breadboardable Artix-7 FPGA Module

    Xilinx has a product brochure that specifies what devices are supported by the free version of Vivado ( they don't make it easy to find it ). This is the sure way to determine if your board will work. Digilent generally offers a voucher for boards that aren't supported by free Vivado. And I hate to gripe about it but why don't posters see the little blurb under the Project Vault heading that says its a place to post project code and not for asking questions? (my eyesight isn't so good so perhaps I shouldn't be the one asking this question ).
  7. Feedback on a register file design?

    Actually, since I just now started reading your code carefully ( you're probably thinking "and you're just telling me this now??" ), there are a number of things that I'd do differently. I suggest that you create a small complete project that you can simulate, and create a bitstream from and test. Look at the post-route timing as you play with the structure. There's a lot of ways to achieve a behavioural result but not many that also scale well with clock frequencies and total design complexity. This is where experience becomes important.
  8. Feedback on a register file design?

    A comment on your latest code. You chose to select the ieee.numeric library. Usually when I do this it's because I know that I'm going to deal with signed and unsigned types. This helps keep my focus on that pesky sign bit. So I generally assign signals to either signed or unsigned types when using ieee.numeric. In general, I use ieee.std_logic_unsigned or ieee.std_logic_signed libraries. The details involved in signals that carry signed or unsigned values can trip you up if you aren't careful. This is especially true if you use multipliers or fractional arithmetic ( a whole fascinating subject in it's own right ). Here's where a good textbook or coding guidelines come into play. A std_logic_vector can always hold signed values but you have to do the bookkeeping. The takeaway is that nothing is chosen randomly, you need to know what consequences of your choices are before you have a large piece of code with hundreds or thousands of lines. The prep work is more important to success (or at least how long it takes to achieve success) than the implementation in my experience. Here is where Dan might point out why he prefers Verilog which has a lineage more like C than VHDL which ADA-like. A lot of nitty-gritty details that your friendly ( or perhaps not so friendly... ) C compiler will take care of for you becomes your responsibility in logic design. PS. so I've avoided directly commenting you your original question until now leaving that up to others. Oh, and one little problem with using good code as a guide is that it probably doesn't have the commentary that points out why the code was written the way that it was... just a fair warning.
  9. Feedback on a register file design?

    Just my (obvious) opinion but I heartily approve... If you were doing this for a living you'd have lots of guidance and known good code to help with this process. On you own it's a bit tougher row to plow. If you look around you can find well written code to help. But nothing, nothing circumvents learning for yourself through experience.
  10. Feedback on a register file design?

    My how this thread has evolved into a life of its own... and I can't resist egging it on. In my experience stupidity and malfeasance on the corporate level rarely has to do with laziness. In order of precedence it would be... ego, attaining or defending status, greed, the fact that most corporations mimic the armed services structure; that is decision making goes down the chain of command and facts rarely travel up the chain, and in large companies departmental tribalism. In my experience merely holding beliefs that counter-indicate prevailing commands ( or failing to cheer on views supporting those commands ) are viewed as mutiny and a threat.
  11. FIFO CDC and Gray codes

    I'd word this as the timing behaviour of flags for two clock FIFOs are not predictable depending on how you might want to use them. Using a clocked signal in one clock domain that has been created in another unrelated clock domain provides the conditions for metastability on a repeatable basis. The effects of metastability is managed not (always) preventable. It is possible to have metastability due to long combinatorial and routing delays as well but this is preventable... and a lot more vexing to identify in working hardware. Metastability is a complex and interesting topic.
  12. FIFO CDC and Gray codes

    Using the hard FIFOs isn't as straightforward as you might assume either. There's some initialization work (reset assertion to when write enable can be asserted) involved that is not well documented in the IP manual. My PMOD challenge in the Project Vault provides an example (Testbed.vhd). It was the first time that I had used the Series 7 hard FIFO primitive and struggled to figure out why it wasn't behaving until I paid attention to a simulation message which led to research and finally figuring out how to use the darn thing.
  13. FIFO CDC and Gray codes

    FIFOs are multi-purpose elements. Single clock FIFOs can be used to absorb bursty data rates when the data sink can't keep up. Dual clock FIFOs are typically used for sending data across clock domains. I emphatically encourage you to carefully read the IP documentation where you will find all kinds of disclaimers, primarily with status flags and word counts, for all vendor supplied 2 clock FIFO IP. Clock domain analysis is a tricky business... you'll find this out for yourself with a bit of sleuthing. Hint: those parity bits are useful for sending status across the domain synchronous with the data. Grey coded counters are very helpful in things like phase modulation applications. They are not a magic band-aid that prevents all problems. The good news is that video applications are pretty tolerant of occasional random errors.
  14. Feedback on a register file design?

    Tell me that I'm an idiot if you want (I really don't mind) but.... I predict a lot less cursing and frustration if you develop the FPGA craft skills before pouring hours into the implementation stage where the initial product is supposed to rival current state of the art processors. The last 20 years has given us hardware optimizations like out-of-order execution, speculative branching and the like and it's just been recently that we've been served the bill ( from a security perspective ). I get the passion. I like it. I don't get masochism. I don't get wanting an end product without wanting to understand the process to achieve it. So I'll channel your moms... "well dear, as long as it makes you happy.."
  15. Feedback on a register file design?