Good points on selecting an ESL solution. Thanks for sharing them.

Some questions on the following point though.

Don’t debug in the RTL:

1) As we know, an ESL model’s ‘high level abstraction event’ will expand into multiple clocks at RTL level after HLS. How would you guarantee a working RTL for highly-clock sensitive blocks such as a write-back Cache Controller where every decision has to be made at clock level on multiple read/write coherent/non-coherent/snoop requests pending from multiple masters.

In other words, if an ESL model is functionally accurate, there is a good chance that the clock accurate RTL will have bugs for multi-master coherent transactions that collide at clock level.

Any solution on such logic from the ESL world?

2) Some have suggested that there are formal tools out there that guarantee equivalence beteween an ESL model and it’s RTL counterpart. Even if such equivalence is established, wouldn’t there be (back to clocks!) concurrency bugs at clock level between blocks that cannot be verified at ESL level (for example a priority encoded arbiter that makes decisions at clock level on who to give grant to).

I note that you do point out that RTL verification is necessary but should not be the starting point. Agreed. But I think that even if ESL models have been thoroughly verified, the RTL based SoC will still need good dose of verification.

Thanks for any input you can share.

Regards.

Thanks, I understand. I will checkout synfora.com and may revert back for additional clarifications.

Regards,

You are really right in saying that only if outcome of the evaluations gets used into some production designs, and it works well, the management will consider a new design flow .

I accept your perspective on DSP implementation vs ESL to FPGA way, though a part of me tells me that ‘DSP is bit more flexible’. Anyhow, the DSP story is not relevant to this thread.

Two more questions:
Q3: What is your take on pros of Synfora viz a viz your competition (like Catapult, AccelChip to name a few…).

Q4: Prior to acquisition by Xilinx, Accelchip was the only company offering a Matlab-to-RTL solution. Rest of the competition was offering C-to-RTL solution. Do you have a take on which one is a better way.

Ps. I used to think Matlab-to-RTL might be preferable, but now am tending towards C-to-RTL.

Very good questions. Here is my reply to both of them.

Q1. The size of the evaluation design has to be representative of what you will try to build as a product using an ESL tool. It is very easy to get impressed by a canned example of an FFT, a filter or some other prebuilt component in the ESL tool library. The real question is, once you try to build something in the order of digital receiver in a 802.11n to ship in your next product, will the tool be able to handle it or leave you without a solution. The digital portion of 802.11a can be a good evaluation candidate, but it is probably going to be mostly throw away work after the evaluation is done. When selecting an evaluation application, you should keep in mind the following. If the evaluation goes well, is this design something that can be used as either a stepping stone or part of a production project.

Q2. For wireless baseband the cost/benefit equation depends on if you are comparing the cost/benefit of taking RTL to a custom ASIC vs a DSP or an FPGA implementation vs a DSP. I will assume you mean FPGA vs DSP as both are readily available off-the-shelf components. I think in this case, algorithmic synthesis tools bridge the usability gap in terms of getting a working design between FPGA and DSP. For cost/benefit, algorithmic synthesis tools allow you to develop your algorithm in a high-level language such as C, which is familiar to DSP designers. Then the tool takes care of the proper RTL generation to get the design working at speed on the FPGA. I think you will see more designs in wireless baseband transition to an FPGA because of the cost/performance point of the part when compared to a DSP, and because of the usability gained by using algorithmic synthesis tools in the design capture phase.

Q2
I think there are two evolution paths for the current hand coded RTL for wirless basebands – a) Using DSP processors capable of vector processing and b) using algorithmic synthesis tools.
From your experience, can you share some cost/benefit analysis of a) vs b).

Thanks,
Krishna

Ps.
Can we have an option to send me an email whenever you have replied to this comment.