Zip CPU @zipcpu

FPGA design engineer and blogger, placing particular emphasis on test and formal verification zipcpu.com Gisselquist Technology, LLC, Joined January 2017

Tweets

8K
Followers

9K
Following

236
Likes

8K

Zip CPU @zipcpu

3 days ago

This stack exchange post has a good description of the problems with using AES-CTR for memory encryption. I love the included pictures. They tell the story well. crypto.stackexchange.com/questions/59/t…

0 0 20 1K 11

View Details

Zip CPU @zipcpu

4 days ago

@TheRetroHQ ROMs take space, but they can be placed on ASICs. It depends on your technology. ROMs that are small enough can be built out of logic. Yes, you can reset an internal RAM from a ROM. You can also use an external flash if necessary.

0 0 1 36 0

View Details

Zip CPU @zipcpu

4 days ago

One of the differences between ASIC and FPGA design is the initial statement. ASICs don't support them. To build IP that works across technologies, I've had to be very careful where, when, and how I use such statements. In many cases, I've had to remove them over time when my FPGA designs later become ASIC designs.

IC Freely 🇨🇦 @intothefloyd

5 days ago

@zipcpu They don't, as long as you define their initial state in register declaration to avoid X's in simulation, and of course to get the initial state that you want, whether 0 or 1.

0 0 3 4K 0

7 3 40 4K 15

View Details

Zip CPU @zipcpu

4 days ago

@bradipao @samsoniuk @ASiDesigner Three examples where memory reset is needed: 1) Security applications, where you have to guarantee no memory leakage, 2) Histogram accumulators, 3) GPS correlation accumulators. These aren't common examples, but they do happen.

1 0 2 34 0

View Details

Zip CPU @zipcpu

4 days ago

@samsoniuk @ASiDesigner It takes work--often a small FSM, coupled with a controller that holds READY low while running. I had to do this with my histogram generator.

0 0 2 40 0

View Details

Zip CPU @zipcpu

4 days ago

Whoever thought AES-CTR could be used to secure memory ... is offering an expensive encryption that looks good but offers zero security.

0 1 11 572 1

View Details

Zip CPU @zipcpu

4 days ago

Sure, I get it. There is one other issue to be aware of: If you get rid of the all internal reset, in favor of an initial statement, then the only way to reset the design will be a full reconfiguring of the FPGA. That's a design choice. Is it what you want? Practically, that's what I used to do. I argued for it often. Then I came across issues with hardware that required resets. (The CPU hit a bug and needs to be reset, but I don't want to reset the whole system, the I2C system locked up, etc.) Resets within the design, even partial ones, can be quite valuable.

1 0 3 70 0

View Details

Zip CPU @zipcpu

4 days ago

In the end, I just had to swallow my pride, say, "Yes, sir! That's a good catch. I'll fix it right away," and then go on with generating a new release. Yes, I knew the first release would've worked, but no one wanted to take that chance on simple trust.

0 0 5 172 0

View Details

Zip CPU @zipcpu

4 days ago

Arguably, the impact of any initial statements within a design on tainting any simulation results is a very real and valid threat to verifying any would-be ASIC IP, so I get their point.

1 0 3 279 0

View Details

Zip CPU @zipcpu

4 days ago

Here's the kicker. In one ASIC project, I was trying to cross from the JTAG clock domain to the system clock and back again. The two domains had separate and independent resets. To be useful, I had to AND the two negative edge resets together, then synchronize their release to get the CDC module to meet its formal assumptions. Crossing reset domains like that breaks timing. I could no longer guarantee setup and hold timing on any of two individual reset paths, I could only accept the violation, accept that it would yield uncertain results for a clock cycle or two, and then go on. It's not ideal, and the hand-waiving stinks. If you can think of a better solution, let me know and I'll try it.

1 0 3 283 3

View Details

Zip CPU @zipcpu

4 days ago

I love the technique. I use it often. It's become a go-to approach for moving everything across clock domains slowly. As a result, the logic quietly moves from one project to another. It's now been in a couple ASIC projects as well. Here's the post for reference: zipcpu.com/blog/2020/10/0…

1 1 8 450 7

View Details

Zip CPU @zipcpu

4 days ago

Some time ago, I posted an article on how to move values and strobes across clock domains. The module was powerful, very versatile, and easy to work with. It had one flaw: it required a reset that would active in both clock domains at the same time, then synchronously release.

1 0 14 950 8

View Details

Zip CPU @zipcpu

5 days ago

One of the challenges I've had with longer resets is that system reset control tends to be at the top level. Hence, when using a longer reset, you can no longer verify low level modules independently. (i.e., you have to assume the longer reset.) So ... this can work ... for some IPs. In this case, you'd need to make sure the input to the 2FF was reset, and then that the longer reset lasted at least 2 clocks in each domain--perhaps longer.

0 0 0 11 0

View Details

Zip CPU @zipcpu

5 days ago

The issue is the missing reset. 2FF synchronizers need asynchronous reset. The reset must have a source, common to both clock domains, and it needs to have a synchronized release in each domain.

Zip CPU @zipcpu

6 days ago

What do you think, anyone see a bug here? It's a basic 2FF CDC crossing, from one clock to another ...

6 3 30 6K 16

2 5 25 2K 23

View Details

Zip CPU @zipcpu

5 days ago

@intothefloyd Yes, there's a difference between a reset synchronizer and a simple 2FF CDC. That said, are you sure that "simple 2FF CDC"s don't need resets? Think that one through.

1 0 1 172 0

View Details

Zip CPU @zipcpu

5 days ago

@zxprojects All good advice, but given that I didn't show you how r_cdrhold_sync was defined, it's not clear this was or would've been a bug.

0 0 0 54 0

View Details

Zip CPU @zipcpu

6 days ago

What do you think, anyone see a bug here? It's a basic 2FF CDC crossing, from one clock to another ...

6 3 30 6K 16

View Details

Zip CPU @zipcpu

5 days ago

@grg_haas The difficult part of FPGA only IP is the customer who shows up at your door wanting an ASIC version. The same goes for ASIC only IP generating an FPGA customer. Practically, that means as much of the IP as possible needs to work for both markets.

0 0 1 59 1

View Details

Zip CPU @zipcpu

5 days ago

For those wanting to know more about this particular signal, it's being used to control the clock and data recovery (CDR) in a Kintex-7 part, used for getting a SATA interface up and running. I'd post more, but ... it's still being debugged, and doesn't fully work yet. I'll post the whole design once it works.

1 1 4 372 1

View Details

Zip CPU @zipcpu

5 days ago

Without such a reset synchronizer, I've seen: 1. A bus request crosses clock domains 2. One (or both) domains gets reset, just not the 2FF synchronizer(s). (The reset doesn't last long enough to clear the 2FF synchronizers either ...) 3. The result is a bus ACK, with no prior request -- a clear violation of all bus protocols.