What is the name of the circuit structure that generates a s

On Saturday, December 22, 2018 at 5:43:51 PM UTC-5, Weng Tianxiang wrote:
You are right. I never say the S0_C1 will be the final logic, but says that the signal must appear during the synthesization.

Again you are mistaken except for the special case of a one-hot encoded single input state machine. Post the source code for something other than that type of state machine that you have actually used along with the synthesis result that produces the S0_C1 signal to provide evidence otherwise you're just making baseless, incorrect statements again.

Kevin
 
On Saturday, December 22, 2018 at 5:43:51 PM UTC-5, Weng Tianxiang wrote:
I think someday they will be introduced into HDL standard.

Even if the patents are useful they wouldn't make it into any language standard...because they are patented. You don't understand how language standards happen, they are not going to take in anything claimed as proprietary.

Google reviewed the applications since 2015/02/18, and finally made a rejection for the offer on 2018/03/16, 7 months after they became patents.

So you're saying that Google reviewed your patents and did not find any value for them as a company. If the patents are so useful shouldn't you be mentioning which companies DID license your patents?

Kevin
 
On 23/12/2018 06:33, gnuarm.deletethisbit@gmail.com wrote:
On Sunday, December 23, 2018 at 12:10:28 AM UTC-5, Weng Tianxiang wrote:
Rick,
...

So what software handles the timing analysis and balances the delays???

If you are expecting the synthesis software to do the heavy lifting of timing analysis, what exactly do your libraries do? What are your three entities?

BTW, do you realize the synthesis software doesn't actually know the timing of an FPGA circuit???

To do a bit of nitpicking, they do (have to for timing optimisations)
and I am not talking about a wire-load model. High-end synthesis tool
offer what is called Physical Aware Synthesis (PAS). What they do is to
run an internal placer (or use the P&R vendors version) and use that to
estimate the timing to a surprising degree of accuracy. Apparently they
do not need to run the actual routing as this is not required for a good
estimate.

>Timing is determined as much by the routing as it is the logic elements.

I would say that for modern FPGA's the routing is normally the timing
killer (on my designs routing delay >2x logic delay). I guess this is
the reason products like Plunify (no affiliation) are so successful.

So it is up to the chip vendor's place and route tools to get that right. This would not be an easy task to accomplish.

And of course all of this ignores the fact that minimum delays are just as important as maximum delays in FPGA logic. It is hard to tell if you could ever get this to work across the three variables of timing, process, voltage and temperature. Every chip will vary. Each board with slightly different PS voltages will vary. Every operating temperature will vary. For a wave pipeline to work all of the inputs to the delay equation have to result in a very small window of delay variation.
How do you plan to control any of that?

Rick C.

Tesla referral code -++ https://ts.la/richard11209
Get 6 months of free supercharging -++

Regards,
Hans
www.ht-lab.com
 
On Sunday, December 23, 2018 at 8:58:36 AM UTC-5, Weng Tianxiang wrote:
On Saturday, December 22, 2018 at 10:34:01 PM UTC-8, gnuarm.del...@gmail.com wrote:
On Sunday, December 23, 2018 at 12:10:28 AM UTC-5, Weng Tianxiang wrote:
Rick,

Here are the main points about my inventions on wave-pipelining circuits:

1. All wave-pipelining circuits will be written in such a code if they were one-cycle logic.

2. Use a link statement linking your wave-pipeling circuit with one of 3 entities I have developed as a wave-pipelining circuit library.

3. A synthesizer generates the wave-pipelined circuit with one or two determined wave-constants passing to the entity.

4. There is no other logic to write.

5. It is specially useful for FPGA if the new HDL rules are accepted into new HDL standard.

6. Theory base: all wave-pipelining circuits are different in their 1-cycle logic, but other logic relating to the wave-pipelining parts are the same and classified into 3 categories that leads to 3 entities.

7. Example circuits: FFT-16; floating A*B --> C;

Weng

So what software handles the timing analysis and balances the delays???

If you are expecting the synthesis software to do the heavy lifting of timing analysis, what exactly do your libraries do? What are your three entities?

BTW, do you realize the synthesis software doesn't actually know the timing of an FPGA circuit??? Timing is determined as much by the routing as it is the logic elements. So it is up to the chip vendor's place and route tools to get that right. This would not be an easy task to accomplish.

And of course all of this ignores the fact that minimum delays are just as important as maximum delays in FPGA logic. It is hard to tell if you could ever get this to work across the three variables of timing, process, voltage and temperature. Every chip will vary. Each board with slightly different PS voltages will vary. Every operating temperature will vary. For a wave pipeline to work all of the inputs to the delay equation have to result in a very small window of delay variation.

How do you plan to control any of that?

Rick C.

Tesla referral code -++ https://ts.la/richard11209
Get 6 months of free supercharging -++

Rick,

Intel first finished its 8087 chip using the wave-pipelining technology. Nowadays every company has the technology. Based on my knowledge, even Chinese Huawei cellphone company uses the technology comfortably.

You are right that Xilinx and Altera also have the potential to control the technology. Nowadays any variations of temperatures, routine delays and voltages are well known and calculated.

The 8087 is not an FPGA. Nothing you have said addresses the fundamental limitations to using wave-pipelining in FPGAs. It doesn't matter if you can calculate the delay variation from PVT or routing. Knowing it isn't the problem, controlling it is. There is nothing the user can do about PVT so it is a variable that blurs the arrival time of the signal to the actual FF. When that blurring becomes wider than a clock cycle you have to slow the clock. Processing variations will likely be the largest contributor and there is nothing to be done about it until they start binning chips for a speed range rather than just maximums.

The other issue that has been pointed out to you is that in FPGAs there are typically an excess of FFs RIGHT NEXT to the LUTs. So if you save FFs by wave-pipelining you have done little if anything. Perhaps a small amount of power.

Rick C.

- Get 6 months of free supercharging
- Tesla referral code - https://ts.la/richard11209
 
On Sunday, December 23, 2018 at 11:43:29 AM UTC-5, HT-Lab wrote:
On 23/12/2018 06:33, gnuarm.deletethisbit@gmail.com wrote:
On Sunday, December 23, 2018 at 12:10:28 AM UTC-5, Weng Tianxiang wrote:
Rick,
..

So what software handles the timing analysis and balances the delays???

If you are expecting the synthesis software to do the heavy lifting of timing analysis, what exactly do your libraries do? What are your three entities?

BTW, do you realize the synthesis software doesn't actually know the timing of an FPGA circuit???

To do a bit of nitpicking, they do (have to for timing optimisations)
and I am not talking about a wire-load model. High-end synthesis tool
offer what is called Physical Aware Synthesis (PAS). What they do is to
run an internal placer (or use the P&R vendors version) and use that to
estimate the timing to a surprising degree of accuracy. Apparently they
do not need to run the actual routing as this is not required for a good
estimate.

I'd love to know more about that. If they don't know the routing in the end design how can they know the timing? I don't know how you would "estimate" the timing. In particular, the timing required by wave-pipelining would be much more detailed than in regular design requiring limits on the minimum AND maximum delays of *each path*, not just logic.

I can't see how this would be possible, much less practical in any real world design other than regular structures like multipliers, etc.


Timing is determined as much by the routing as it is the logic elements.

I would say that for modern FPGA's the routing is normally the timing
killer (on my designs routing delay >2x logic delay). I guess this is
the reason products like Plunify (no affiliation) are so successful.

So it is up to the chip vendor's place and route tools to get that right.. This would not be an easy task to accomplish.

And of course all of this ignores the fact that minimum delays are just as important as maximum delays in FPGA logic. It is hard to tell if you could ever get this to work across the three variables of timing, process, voltage and temperature. Every chip will vary. Each board with slightly different PS voltages will vary. Every operating temperature will vary. For a wave pipeline to work all of the inputs to the delay equation have to result in a very small window of delay variation.
How do you plan to control any of that?

Rick C.

+ Get 6 months of free supercharging
+ Tesla referral code - https://ts.la/richard11209
 
On 23/12/2018 17:56, gnuarm.deletethisbit@gmail.com wrote:
On Sunday, December 23, 2018 at 11:43:29 AM UTC-5, HT-Lab wrote:
...
To do a bit of nitpicking, they do (have to for timing optimisations)
and I am not talking about a wire-load model. High-end synthesis tool
offer what is called Physical Aware Synthesis (PAS). What they do is to
run an internal placer (or use the P&R vendors version) and use that to
estimate the timing to a surprising degree of accuracy. Apparently they
do not need to run the actual routing as this is not required for a good
estimate.

I'd love to know more about that. If they don't know the routing in the end design how can they know the timing?

Unfortunately I don't have much info on this, perhaps somebody else on
this ng knows how it all works. I suspect that placement will allow you
to identified the long tracks and congested areas, a wire-load model can
then be used for final bits.

>I don't know how you would "estimate" the timing. In particular, the timing required by wave-pipelining would be much more detailed than in regular design requiring limits on the minimum AND maximum delays of *each path*, not just logic.

I agree, but I was not talking about wave-pipelining, just regular
synthesis.

Regards,
Hans
www.ht-lab.com
 

Welcome to EDABoard.com

Sponsor

Back
Top