7 ms·

I DO want access to timing as most of what I want to use an FPGA to implement directly relates to timing. Think: real-time audio.

ianhowson 7y ago
Sure. Then why not use a DSP? Then you've got lower price, easier programming and can still achieve cycle-accurate timing if you desire.
- nitrogen 7y ago
  The DSP is great for the computation side of audio, but unless that DSP has every bus you want to interface with, you also need an FPGA for I/O routing to PCI, Ethernet, ADCs and DACs, etc.
reitzensteinm 7y ago
Is this really the case? The timing parent is talking about is fractions of a cycle, maybe five orders of magnitude above audible frequencies. How could you take advantage of exposed timing?
- _iiu1 7y ago
  1) multiplexed audio. Sure, your frame clock may only be 44.1khz, but the bit clock on a mere 8 channels of this will be 11.2896mhz, to say nothing of oversampling, to say nothing of processing 2) low latency processing of the above may require in-situ pipelining in which the pass-through buffer itself IS the processing buffer, etc. imagine being able to eat the pot you boil your pasta in. 3) why WOULDN'T any well-designed elegant system have every single tick as a function of that bit clock? It makes no sense to deliberately place spanners in your own path, particularly as pertains to jitter etc. It's not like you are going to pause your wavelet transform and check your email in process...
- justaaron 7y ago
  point being: Control. Precise control over timing is required for deterministic temporal activities. Removing precise control over timing from the language stack one uses to program FPGA's with is removing a desirable feature for many of their uses cases. If one is interesting in glossing over all this abstraction, why is one wishing to use an FPGA at all? I will reverse the question and say: "in which scenarios is someone hoping to avoid addressing precise timing constructs in FPGA programming?" Obviously I'm not referring to clock propagation delay or quantum entanglement etc LOL I mean the intentional macro stuff wrt "timing"
  - reitzensteinm 7y ago
    Parent was referring to clock propagation delay (resulting in multiple clock domains on the same chip), hence my confusion. If you're talking about higher level timing, nobody is arguing for taking that away from you.
    - justaaron 7y ago
      I agree. I've seen System-Verilog used for simulating such propagation delays, but it's not exactly a language-abstractable concept yet (precisely as it involves the actual hardware gate implementation) in that such black-box simulations estimate average propagation delay as a fixed function dependent upon results obtained from testing specific functionality blocks in specific devices specific gate-counts away from I/O pins, etc. It would be highly desirable to have HDL level modeling of this stuff in the abstract sense, although I confess to not knowing how that could possibly work, given the above.

ianhowson 7y ago

Sure. Then why not use a DSP? Then you've got lower price, easier programming and can still achieve cycle-accurate timing if you desire.

nitrogen 7y ago
The DSP is great for the computation side of audio, but unless that DSP has every bus you want to interface with, you also need an FPGA for I/O routing to PCI, Ethernet, ADCs and DACs, etc.

reitzensteinm 7y ago

Is this really the case? The timing parent is talking about is fractions of a cycle, maybe five orders of magnitude above audible frequencies. How could you take advantage of exposed timing?

_iiu1 7y ago
1) multiplexed audio. Sure, your frame clock may only be 44.1khz, but the bit clock on a mere 8 channels of this will be 11.2896mhz, to say nothing of oversampling, to say nothing of processing 2) low latency processing of the above may require in-situ pipelining in which the pass-through buffer itself IS the processing buffer, etc. imagine being able to eat the pot you boil your pasta in. 3) why WOULDN'T any well-designed elegant system have every single tick as a function of that bit clock? It makes no sense to deliberately place spanners in your own path, particularly as pertains to jitter etc. It's not like you are going to pause your wavelet transform and check your email in process...
justaaron 7y ago
point being: Control. Precise control over timing is required for deterministic temporal activities. Removing precise control over timing from the language stack one uses to program FPGA's with is removing a desirable feature for many of their uses cases. If one is interesting in glossing over all this abstraction, why is one wishing to use an FPGA at all? I will reverse the question and say: "in which scenarios is someone hoping to avoid addressing precise timing constructs in FPGA programming?" Obviously I'm not referring to clock propagation delay or quantum entanglement etc LOL I mean the intentional macro stuff wrt "timing"
- reitzensteinm 7y ago
  Parent was referring to clock propagation delay (resulting in multiple clock domains on the same chip), hence my confusion. If you're talking about higher level timing, nobody is arguing for taking that away from you.
  - justaaron 7y ago
    I agree. I've seen System-Verilog used for simulating such propagation delays, but it's not exactly a language-abstractable concept yet (precisely as it involves the actual hardware gate implementation) in that such black-box simulations estimate average propagation delay as a fixed function dependent upon results obtained from testing specific functionality blocks in specific devices specific gate-counts away from I/O pins, etc. It would be highly desirable to have HDL level modeling of this stuff in the abstract sense, although I confess to not knowing how that could possibly work, given the above.