Digital Replacing Analog

probably need voting mechanism and ways to do periodic resets

mbinations of inputs it it need not be treated as software

If the design contains sequential logic that gets a lot harder. I assume t hat "all possible" combinations don't need to be tested, only the ones that are connected since "all possible" would need to also include every combin ation of FF states whether or not they are intended.

Back some years ago it was a hot research topic to figure out how to genera te test vectors for designs and how to determine coverage and testability. For a complex design it can be a complex issue, but not the same thing as verifying a design does what you have stated in the requirements. Even har der is to verify the design does what you desire.

And there's /another/ source of problems.

Does the simulator you use model inertial delays or transport delays?

I'm sensitive to that since almost 40 years ago, before FPGAs existed, I created an implementation. It simulated correctly in an inertial delay simulator (HiLo), but correctly showed a problem in a transport delay simulator (Tegas).

Spotting that infelicity saved 3 months turnaround time and a years salary (it was a semi-custom design).

Those details don't matter; what matters is that the correctness of the simulator has to be questioned - and answered.

And also to determine which manufacturing defects should be tested. It used to be nodes stuck-at-1 and stuck-at-0; I don't know what the latest models are.

FPGAs are easier that hardwired logic, since you only need to test the generic "uncommitted" LUT and interconnections, not the specific ones in the customer's design.

It is entirely different, which beginners often don't appreciate.

That's design validation, which is yet another thing.

"Do the right thing" "Do the thing right" "Duplicate the thing exactly"

wn

What were you doing that the transport and inertial delays mattered? My un derstanding is that these are issues in logic simulators... where the stand ard assumption is that all logic is perfectly fast and only the logic is be ing verified before any synthesis is done. There are other tools to verify the actual timing of the implementation as a prelude to testing in the lab .

I did meet a designer giving a presentation at work who claimed that timing was best verified by timing simulations. I asked how he proposed designin g the test bench to verify all paths through all logic and his reply was so mething equivalent to "very carefully".

Who exactly are you arguing with? With Klaus or the Approval Body? How is this going to help with the latter? Will you be able to outrant them and get a medical device approval? If so, best of British luck!

Best regards, Piotr

That would take too long to explain, and the precise details are somewhat hazy.

The core point was that an internal dynamic hazard glitch was theoretically possible, even in a nominally fully synchronous design.

Once that possibility was recognised, I corrected my design fault.

I doubt that, and I'm surprised someone with your experience asks the question. If that was the case: - how could the simulator indicate a pre-P&R or post-P&R max clock speed? - how could the P&R choose which paths to optimise?

In FPGAs and similar I've only seen digital logic simulators that include the timing. I don't see much use for a digital logic simulator that doesn't.

lary

Without more details I can't evaluate your issue. But I don't know of any tools that are perfect. So what is the point of this line of thought exact ly?

gic is

Asks what question??? A simulator is not used to measure clock speeds. An ything pre P&R is just a wild guess. After P&R it is a a worst case analys is... that's not always right. In particular I worked on a project where t hey knew the tools were broken. So we had to test the design on the bench with a heater to try to make it fail... sometimes when the timing wasn't qu ite bad enough to fail at room temperature. We generated multiple trials e very night and tested the best one until we got one to work no matter what we did to it.

lab.

I have no idea why you say that. If you are using a simulator to analyze y our timing, I can understand why you think FPGA design is a PITA. Timing i s analyzed by a... timing analysis tool. It's a matter of adding up all th e many combinations of paths and comparing them to the timing requirements. It's an exhaustive search and either all paths pass or you get errors tha t are up to you to figure out how to fix.

It would be nearly impossible to cover all the paths in a simulation and it would require a special tool to analyzed how much of the design was covere d by any given test.

Maybe by timing, you mean they tick off the time that is marked by the cloc ks in the system. Yeah, they do that, but there are no delays in the signa l paths unless you go to great pains to add them. Before place and route t here is no accurate timing information to work with.

Use the right tool for the right job. Use simulation to verify the logic i s correct. Then synthesize the design and go to work on the timing verific ation.

What makes you think your evaluating an issue that occurred in ~1983 would be beneficial?

I refer you to the first line of my response dated On Monday, August 31, 2020 at 7:29:25

I should have said "makes that statement/assertion".

So you recognise that "the standard assumption is that all logic is perfectly fast" isn't actually the case.

Good.

It is difficult (and pointless) to assess what you might mean by "wild".

And what could you /guarantee/ after that rather suboptimal process?

What makes you assert that I think FPGA design is a PITA?

We seem to be making no headway. I don't know what experience you actually have with digital design, but if you don't understand anything I am talking about we have no common ground to continue this discussion.

Yes, I think if you don't know what is meant by a "wild guess" then we truly have no common ground for discussion.

There are NO guarantees in life. We shipped product. This was a company that provided test equipment to the majority of the telecom manufacturers in the world.

So you don't deny it?

I can't say for sure what you are doing, buy if you are analyzing timing through simulation, I'm pretty sure you have lots of timing bugs or you spend *way* too much time in simulation looking for them or both.

I thought I've explained the preferred process pretty clearly. If you have any questions feel free to ask.

Correct, no progress

I suggest you approach the Approval Body like Piotr suggested

You should do that anyway, no point in digging to deep before you know what you need to comply to. My guess is that you will have an eyeopening experience :-)

Cheers

Klaus

Just so, and I suspect the result will be a "stomach sinking" or "bowel opening" experience :)

Quote

This is a neat and commercially important example of your limited imagination and understanding; The HP 94332 Nanoprocessor.

Given its characteristics, do you think it is a processor or not?

"The Nanoprocessor was more of a state-machine controller than a microprocessor."

"This code is from the interrupt handler that increases the time and date every second. The code below determines ... the corresponding opcode, and my description of the instruction. ... This code demonstrates that even though a processor without addition sounds useless, the Nanoprocessor's bit operations and increment/decrement allow more computation than you'd expect. It also shows that Nanoprocessor code is compact and efficient. Many things can be done in a single byte (such as bit test and skip) that would take multiple bytes on other processors. The Nanoprocessor's large register file also avoids much of the tedious shuffling of data back and forth often required in other processors. Although some call the Nanoprocessor more of a state machine controller than a microprocessor, that understates the capabilities and role of the Nanoprocessor."

RE

on

the

hey

their

ernal

ry

the

e a

igns

If

can be

cessor."

So we are attempting to define "processor" by example? Yes, I consider thi s to be a processor because it executes a program stored in memory, generat ed from code whose use is only to specify the instructions.

But this is not about what I consider to be a processor. The issue is what does the standard consider to be a processor? No?

I suppose the standard is flexible enough to give you the rope to hang your self. It sounds like a lot of adherence to the spec requires the developer s to make their own definitions and to justify those definitions.

A lot of people are criticizing this project as being unrealistic in consid eration of the difficulties of getting medical equipment approved. I don't disagree with that assessment. But that doesn't mean I should abandon the effort rather than putting time and interest into doing as good a job as I can. 6 weeks ago I was the guy trying to get them to write requirements f or the hardware in addition to the software in the face of "we don't have t ime to do it right" sort of severe resistance.

At this point I am doing most of the electronic design and am making a requ irements document for the FPGA which I won't consider coding until it is co mplete and the stake holders have signed off on. The project leader does n ot understand the issue of measuring twice so we can cut once. You literal ly would not believe the number and severity of issues with the first revs of the control board.

I was about to exit the project because I thought my role was about done. Now it looks like I'm the lead hardware designer and my biggest problem wil l be debugging the thing without equipment. At least I have a good relatio nship with the software guys. If I get my hands on a machine I'll be insta lling a Forth interpreter so I can get it to do what I need.

Right now I'm trying to figure out how to calibrate the sensors in the use cases for the machine. I think it will need two calibration modes. One to calibrate the offset of the various sensors which can be one without speci al equipment. Another calibration mode will be required to fully calibrate the O2 sensor at normal O2 content and 100% O2. This requires the use of an O2 supply, so it is a separate calibration. It's required because the O

Quote

You really should consider taking up Piotr's/Anthony's/my suggestion of approaching the Approval Body.

But hey, knock yourself out!