Dynamic product terms

[Anonymous]

Is it possible to directly alloctate individual PLD blocks within Verilog components, then using the resulting cyfitter mapping from C code to dynamically reprogram the product terms?

   

Essentially I am looking to compare parallel input signals against an array of test keys, where the routing is fixed but the comparands (and masking) need to be reprogrammed at run-time.

   

One alternative scheme would be to use an array of time-multiplexed datapaths with parallel inputs. Perhaps the FIFOs can be made to store four key bytes each by cyclically underflowing the buffers. The parallel inputs seem to eat a lot of status cells though.

   

Unfortunately indexed DMA appears to carry a sufficiently long latency to be impractical for this use unless perhaps the triggers are speculated early. Plus they can't reach the bit-banded SRAM region. A final option might be to spring for a DFB-equipped part and try some form of hash-table comparison against the internal memory there, though I honestly don't know whether this is feasible.

   

Lastly a disclaimer: I'm still very much new to the PSoC environment and this HDL business in general and so I still only have a faint idea of how to get the most out of these resources. Feel free to suggest any alternative means of achieving the same ends if dynamic PLD components are infeasible.

[odissey1]

I do not understand your project, but believe that this can be accomplished in pure verilog. Basically, there is parallel input and some compare/mask registers of same width which can be updated by API, is that what you want? 

[Anonymous]

To be honest, I am not quite certain.

   

To give you a bit of  context the application is a debugger where the system sniffs on an address bus and compares these, along with a few odd control signals, against an array of breakpoints resulting in a combined hit/miss indicator for the bus cycle. There is no fixed target amount but obviously the more of these I can squeeze in, the better.

   

Anyway. I think you are referring to setting up datapaths with parallel inputs to capture the addresses and using the arithmetic compare functions for testing against breakpoint values stored in the register(s). If so that is the scheme I have been using so far and which does indeed work. Unfortunately it is somewhat resources hungry, yielding two 8-bit comparators per UDB datapath. Perhaps five by time-multiplexing the Ax/Dx/Fx registers.

   

On paper the PLDs would also appear to be well-suited for this purpose and I was hoping to try them as an alternative. The address bits would be mapped onto the inputs PLD inputs with each of the product terms serving as an individual comparator, yielding 8x2 12-bit comparators per UDB. Admittedly there is also more to it when chaining wider than comparators but that was my basic idea.

   

Frankly this whole progrWhat couldn't figure out was how to explicitly allocate 12C4 PLD blocks with the desired input/output routing such that the true/complement configuration registers forming the product terms may be programmed at run-time. Perhaps this isn't supported but the architecture manual mentions reading the parallel PLD outputs directly in code so I figured it might be an intended use case.

   

Honestly this whole programmable hardware business is a bit of a jungle to me. All the new options in optimizing a design to make the best use of the available resources is both a challenge and a curse for a performance-oriented coder.

[Bob_Marlowe]

Probably I am thinking too simple:

   

Why not using a bunch (there are 24 in a PSoC5) of comparators together with control registers to set values to compare to. Even digital muxes could be used to path the signals. Programming the PLD are on-the-fly will turn out to be complicated. There are "registers" (in fact memory locations) that perform the PLD function, but you would have to provide your own "PLD assembler" as in the '80

   

Just a thought.

       

Bob

[Anonymous]

That does indeed sound quite reasonable and is essentially the strategy which I have been using up to now. I am not clear on which multiplexers you are referring to however. Is there a another means of routing the parallel inputs more efficiently in order to conserve resources?

   

With ~18-bits to match and probably 9 UDBs to spare for the purpose I believe I would get 15 comparators in total. With PLDs I believe I could get another 72 within the same area. Or more likely free up some of the UDBs/datapaths for other uses while avoiding time-multiplexing.

   

The PLD programming should be trivial for this particular case. Each product term would test one address vector, with a "true" setting on one input matching a one-bit on the corresponding address line input and conversely a "complement" setting matching zero. These would be poked in via the corresponding Bx_Px_Ux_PLDx_ITx T/C register bits. Though admittedly there is a bit more to it for chaining two 12-bit terms with only 4-outputs.

   

The tricky bit is the routing fabric and timing constraints which seem highly impractical to encode by hand without partial compiler support. I think the routing is even documented to the level which would be required for hand-assembling a configuration.

   

In any event my application doesn't exactly stand or fall with this ability. It would simply be a neat optimization and perhaps an introduction to lower-level dynamic device reconfiguration, which I anticipate being useful to efficiently accommodate multiple disparate execution modes within a limited logic space towards the end of the project.

[Bob_Marlowe]

Look here to find PALASM sources in FORTRAN. When re-written for C you might be able to get the register settings of your PSoC out of them. A funny story: Me and my late collegue W-R Schwan wrote the first PALASM for MMI in 1982 which was later expanded by MMI to use the more complex devices as the PAL22V10

       

Bob