It may take a little effort and time to infer complex things using RTL,
but the simulation performance has always been well worth the effort
for me. Simulating the instantiated primitives is _very_ slow compared
to RTL.
Andy
MM wrote:
> Robin,
>
> IMHO, trying to get inferring of anything more complex than a flip-flop, or
> perhaps an adder, to work is a waste of time. Just instantiate what you
> need...
>
> /Mikhail
Reply by Robin Bruce●July 6, 20062006-07-06
Guys,
Given feedback I've had from Xilinx, It seems that this is something
that should be possible today but isn't. Apparently a bugfix has been
made that should fix this and it will be released with ISE 9.1
Robin
Robin Bruce wrote:
> OK,
>
> so if I've understood this properly, instead of registering the inputs
> by differing amounts in order to account for the PREG cascade at the
> outputs, everything is getting (pointlessly) registered by the same
> amount at the input, and then summed together combinatorily at the
> output of DSP48s, followed by some more pointless registering occurs at
> the output?
>
> My interest in this is fairly academic really... The design from which
> this question arose has a 35x35 multiplier generated using CoreGen, so
> it works fine. It would be useful from a design methodology perspective
> to have the ability to infer the DSP48s in such a simple manner. It
> would make autogenerating VHDL for different pipelined multiplier
> structures a walk in the park. I'm not necessarily of the opinion that
> this should be possible today, just that it would be really nice and
> when I came across sources that suggested it was possible to do this in
> a high performance manner I decided to try it. (XtremeDSP for Virtex-4
> FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf
> & Philippe Garrault, Accelerate design performance with HDL coding
> practices)
>
> I've been really impressed with both the informal (via Ben Jones) and
> formal (via tech support) reaction to me bringing this up with Xilinx,
> so even if this has all come from me being a bit naive about the
> capabilities of XST, there seem to be people in Xilinx who believe that
> we should be able to be so naive and expect good performance at the
> same time.
>
> Still very much a beginner,
>
> Robin
>
> >Ray Andraka wrote:
> > Robin Bruce wrote:
> >
> > > Martin,
> > >
> > >
> > >>Have you had a look in FPGA editor to see what's going on?
> > >
> > >
> > > This is where I myself look dim: I did open up the NCD file in the FPGA
> > > Editor. I didn't really know what to do to tell if the right
> > > registering was occurring. All I could see was that all 4 DSP48s were
> > > instantiated together in a little row. I've never used FPGA editor
> > > before. I'm more familiar with PlanAhead for looking at that sort of
> > > thing, but I don't have that on my laptop, my current working platform.
> > >
> > >
> > >>Is it actually this bit of code that limits the timing?
> > >
> > >
> > > Well, all I can say is that I don't think so. It could very well be
> > > though, but I've tried writing the VHDL in very different ways, guided
> > > by things I've found in one or two guides to instantiating the DSP48s
> > > in VHDL. Every way I write the VHDL, the same performance is obtained.
> > > The thing is that I can see that the synthesis tool is making some kind
> > > of effort to pipeline the thing.
> > >
> > > This is the critical path that comes out of the synthesis report if
> > > this means anything to anyone:
> > >
> > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > > Gate Net
> > > Cell:in->out fanout Delay Delay Logical Name (Net Name)
> > > ---------------------------------------- ------------
> > > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > > mult_inst/Mmult__n00002
> > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > > mult_inst/Mmult__n00003
> > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> > > (mult_inst/Mmult__n0000_s_69)
> > > FD:D 0.391 mult_inst/Mmult__n0000_0
> > > ----------------------------------------
> > > Total 12.320ns (11.786ns logic, 0.534ns route)
> > > (95.7% logic, 4.3% route)
> > >
> > > Cheers,
> > >
> > > Robin
> > >
> >
> > Your design is not inferring the P register, so the adders are
> > combinatorial. The adders get connected in a daisy chain. You may have
> > to recode your RTL to reflect that, as the synthesizer is not really
> > smart enough to push around the registers to the degree necessary to
> > deal with differing latencies among the adder inputs.
Reply by Robin Bruce●July 6, 20062006-07-06
OK,
so if I've understood this properly, instead of registering the inputs
by differing amounts in order to account for the PREG cascade at the
outputs, everything is getting (pointlessly) registered by the same
amount at the input, and then summed together combinatorily at the
output of DSP48s, followed by some more pointless registering occurs at
the output?
My interest in this is fairly academic really... The design from which
this question arose has a 35x35 multiplier generated using CoreGen, so
it works fine. It would be useful from a design methodology perspective
to have the ability to infer the DSP48s in such a simple manner. It
would make autogenerating VHDL for different pipelined multiplier
structures a walk in the park. I'm not necessarily of the opinion that
this should be possible today, just that it would be really nice and
when I came across sources that suggested it was possible to do this in
a high performance manner I decided to try it. (XtremeDSP for Virtex-4
FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf
& Philippe Garrault, Accelerate design performance with HDL coding
practices)
I've been really impressed with both the informal (via Ben Jones) and
formal (via tech support) reaction to me bringing this up with Xilinx,
so even if this has all come from me being a bit naive about the
capabilities of XST, there seem to be people in Xilinx who believe that
we should be able to be so naive and expect good performance at the
same time.
Still very much a beginner,
Robin
>Ray Andraka wrote:
> Robin Bruce wrote:
>
> > Martin,
> >
> >
> >>Have you had a look in FPGA editor to see what's going on?
> >
> >
> > This is where I myself look dim: I did open up the NCD file in the FPGA
> > Editor. I didn't really know what to do to tell if the right
> > registering was occurring. All I could see was that all 4 DSP48s were
> > instantiated together in a little row. I've never used FPGA editor
> > before. I'm more familiar with PlanAhead for looking at that sort of
> > thing, but I don't have that on my laptop, my current working platform.
> >
> >
> >>Is it actually this bit of code that limits the timing?
> >
> >
> > Well, all I can say is that I don't think so. It could very well be
> > though, but I've tried writing the VHDL in very different ways, guided
> > by things I've found in one or two guides to instantiating the DSP48s
> > in VHDL. Every way I write the VHDL, the same performance is obtained.
> > The thing is that I can see that the synthesis tool is making some kind
> > of effort to pipeline the thing.
> >
> > This is the critical path that comes out of the synthesis report if
> > this means anything to anyone:
> >
> > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > Gate Net
> > Cell:in->out fanout Delay Delay Logical Name (Net Name)
> > ---------------------------------------- ------------
> > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00002
> > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00003
> > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> > (mult_inst/Mmult__n0000_s_69)
> > FD:D 0.391 mult_inst/Mmult__n0000_0
> > ----------------------------------------
> > Total 12.320ns (11.786ns logic, 0.534ns route)
> > (95.7% logic, 4.3% route)
> >
> > Cheers,
> >
> > Robin
> >
>
> Your design is not inferring the P register, so the adders are
> combinatorial. The adders get connected in a daisy chain. You may have
> to recode your RTL to reflect that, as the synthesizer is not really
> smart enough to push around the registers to the degree necessary to
> deal with differing latencies among the adder inputs.
Reply by Ray Andraka●July 5, 20062006-07-05
Robin Bruce wrote:
> Martin,
>
>
>>Have you had a look in FPGA editor to see what's going on?
>
>
> This is where I myself look dim: I did open up the NCD file in the FPGA
> Editor. I didn't really know what to do to tell if the right
> registering was occurring. All I could see was that all 4 DSP48s were
> instantiated together in a little row. I've never used FPGA editor
> before. I'm more familiar with PlanAhead for looking at that sort of
> thing, but I don't have that on my laptop, my current working platform.
>
>
>>Is it actually this bit of code that limits the timing?
>
>
> Well, all I can say is that I don't think so. It could very well be
> though, but I've tried writing the VHDL in very different ways, guided
> by things I've found in one or two guides to instantiating the DSP48s
> in VHDL. Every way I write the VHDL, the same performance is obtained.
> The thing is that I can see that the synthesis tool is making some kind
> of effort to pipeline the thing.
>
> This is the critical path that comes out of the synthesis report if
> this means anything to anyone:
>
> Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> Gate Net
> Cell:in->out fanout Delay Delay Logical Name (Net Name)
> ---------------------------------------- ------------
> DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> DSP48:PCIN47->PCOUT47 1 2.363 0.000
> mult_inst/Mmult__n00002
> (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> DSP48:PCIN47->PCOUT47 1 2.363 0.000
> mult_inst/Mmult__n00003
> (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> (mult_inst/Mmult__n0000_s_69)
> FD:D 0.391 mult_inst/Mmult__n0000_0
> ----------------------------------------
> Total 12.320ns (11.786ns logic, 0.534ns route)
> (95.7% logic, 4.3% route)
>
> Cheers,
>
> Robin
>
Your design is not inferring the P register, so the adders are
combinatorial. The adders get connected in a daisy chain. You may have
to recode your RTL to reflect that, as the synthesizer is not really
smart enough to push around the registers to the degree necessary to
deal with differing latencies among the adder inputs.
Reply by Ray Andraka●July 5, 20062006-07-05
Robin Bruce wrote:
> Thanks Ben,
>
> it's always good to know that I'm not imagining the problem. I'm using
> ISE 8.1, service pack 3. I should probably point out at this point that
> the purpose of this little project is as much about design methodology
> as it is about having a functioning design. I'm aware that there's
> about a million ways I could do this, but in order to have a portable
> core that can be easily floorplanned, I want to have all my design
> files as standard VHDL with no specific instantiations of FPGA
> resources, nor any NGC files from CoreGen.
>
>
>
You'll generally have far better results instantiating the DSP48's with
everything set up the way you want it. I realize you want RTL-only for
portability. How about instead putting a wrapper around the DSP48
instantiation so that it appears as a generic pipelined multiplier. If
you port to another device, just replace the wrapper with one
appropriate for that device. If you want, put your wrapper file(s) in a
separate subdirectory so that you can quickly identify which ones need
to be replaced if you make a technology change. Making up new wrappers
for a new device should not require much effort or time.
Reply by Robin Bruce●July 5, 20062006-07-05
Hmmm.... that looks fairly mangled. Try again...
Incidentally, these are for an unsigned version of the problem I've
been describing, for which the problem is the same.
DSP48 Name DSP1 DSP2 DSP3 DSP4
AREG 2 2 2 2
BREG 2 0 2 0
CREG 0 0 0 0
MREG 0 0 0 0
PREG 0 0 0 0
LEGACY_MODE MULT18X18
CARRYINSELREG 0 0 0 0
OPMODEREG 0 0 0 0
SUBTRACTREG 0 0 0 0
CARRYINREG 0 0 0 0
B_INPUT DIRECT CASCADE DIRECT CASCADE
Robin
>
>
> Martin Thompson wrote:
> > "Robin Bruce" <robin.bruce@gmail.com> writes:
> >
> > > Martin,
> > >
> > > > Have you had a look in FPGA editor to see what's going on?
> > >
> > > This is where I myself look dim: I did open up the NCD file in the FPGA
> > > Editor. I didn't really know what to do to tell if the right
> > > registering was occurring. All I could see was that all 4 DSP48s were
> > > instantiated together in a little row. I've never used FPGA editor
> > > before. I'm more familiar with PlanAhead for looking at that sort of
> > > thing, but I don't have that on my laptop, my current working platform.
> > >
> >
> > I haven't looked at a V-4 in FPGA editor... but if you go to one of
> > your DSP48 blocks and double click it, can you see the intrnals of it
> > and are there some boxes that are filled in for the use of registers?
> >
> > > This is the critical path that comes out of the synthesis report if
> > > this means anything to anyone:
> > >
> > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > > Gate Net
> > > Cell:in->out fanout Delay Delay Logical Name (Net Name)
> > > ---------------------------------------- ------------
> > > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > > mult_inst/Mmult__n00002
> > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > > mult_inst/Mmult__n00003
> > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> > > (mult_inst/Mmult__n0000_s_69)
> > > FD:D 0.391 mult_inst/Mmult__n0000_0
> > > ----------------------------------------
> > > Total 12.320ns (11.786ns logic, 0.534ns route)
> > > (95.7% logic, 4.3% route)
> > >
> >
> > That looks like a cascade-chain... because your inputs are 35 bits
> > wide and you use more than one multiplier, they need to cascade. This
> > can be pipelined (by the look of the DSP48 diagram in UG073), but how
> > you'd infer that I have no idea :-( You may have to infer the
> > individual multipliers and the regs between them. But at that point,
> > you might as well instantiate them!
> >
> > Cheers,
> > Martin
> >
> > --
> > martin.j.thompson@trw.com
> > TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> > http://www.trw.com/conekt
Reply by Robin Bruce●July 5, 20062006-07-05
Here's a little table I've knocked up after looking at those DSP48s in
the FPGA editor:
DSP48 Name Mmult__n00001 Mmult__n00002 Mmult__n00003 Mmult__n00004
AREG 2 2
2 2
BREG 2 0
2 0
CREG 0 0
0 0
MREG 0 0
0 0
PREG 0 0
0 0
LEGACY_MODE MULT18X18 MULT18X18 MULT18X18 MULT18X18
CARRYINSELREG 0 0 0
0
OPMODEREG 0 0 0
0
SUBTRACTREG 0 0 0
0
CARRYINREG 0 0 0
0
B_INPUT DIRECT CASCADE DIRECT
CASCADE
Cheers,
Robin
Martin Thompson wrote:
> "Robin Bruce" <robin.bruce@gmail.com> writes:
>
> > Martin,
> >
> > > Have you had a look in FPGA editor to see what's going on?
> >
> > This is where I myself look dim: I did open up the NCD file in the FPGA
> > Editor. I didn't really know what to do to tell if the right
> > registering was occurring. All I could see was that all 4 DSP48s were
> > instantiated together in a little row. I've never used FPGA editor
> > before. I'm more familiar with PlanAhead for looking at that sort of
> > thing, but I don't have that on my laptop, my current working platform.
> >
>
> I haven't looked at a V-4 in FPGA editor... but if you go to one of
> your DSP48 blocks and double click it, can you see the intrnals of it
> and are there some boxes that are filled in for the use of registers?
>
> > This is the critical path that comes out of the synthesis report if
> > this means anything to anyone:
> >
> > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > Gate Net
> > Cell:in->out fanout Delay Delay Logical Name (Net Name)
> > ---------------------------------------- ------------
> > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00002
> > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00003
> > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> > (mult_inst/Mmult__n0000_s_69)
> > FD:D 0.391 mult_inst/Mmult__n0000_0
> > ----------------------------------------
> > Total 12.320ns (11.786ns logic, 0.534ns route)
> > (95.7% logic, 4.3% route)
> >
>
> That looks like a cascade-chain... because your inputs are 35 bits
> wide and you use more than one multiplier, they need to cascade. This
> can be pipelined (by the look of the DSP48 diagram in UG073), but how
> you'd infer that I have no idea :-( You may have to infer the
> individual multipliers and the regs between them. But at that point,
> you might as well instantiate them!
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.trw.com/conekt
Reply by ●July 5, 20062006-07-05
"Robin Bruce" <robin.bruce@gmail.com> writes:
> Martin,
>
> > Have you had a look in FPGA editor to see what's going on?
>
> This is where I myself look dim: I did open up the NCD file in the FPGA
> Editor. I didn't really know what to do to tell if the right
> registering was occurring. All I could see was that all 4 DSP48s were
> instantiated together in a little row. I've never used FPGA editor
> before. I'm more familiar with PlanAhead for looking at that sort of
> thing, but I don't have that on my laptop, my current working platform.
>
I haven't looked at a V-4 in FPGA editor... but if you go to one of
your DSP48 blocks and double click it, can you see the intrnals of it
and are there some boxes that are filled in for the use of registers?
> This is the critical path that comes out of the synthesis report if
> this means anything to anyone:
>
> Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> Gate Net
> Cell:in->out fanout Delay Delay Logical Name (Net Name)
> ---------------------------------------- ------------
> DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> DSP48:PCIN47->PCOUT47 1 2.363 0.000
> mult_inst/Mmult__n00002
> (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> DSP48:PCIN47->PCOUT47 1 2.363 0.000
> mult_inst/Mmult__n00003
> (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> (mult_inst/Mmult__n0000_s_69)
> FD:D 0.391 mult_inst/Mmult__n0000_0
> ----------------------------------------
> Total 12.320ns (11.786ns logic, 0.534ns route)
> (95.7% logic, 4.3% route)
>
That looks like a cascade-chain... because your inputs are 35 bits
wide and you use more than one multiplier, they need to cascade. This
can be pipelined (by the look of the DSP48 diagram in UG073), but how
you'd infer that I have no idea :-( You may have to infer the
individual multipliers and the regs between them. But at that point,
you might as well instantiate them!
Cheers,
Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
Reply by Robin Bruce●July 4, 20062006-07-04
Martin,
> Have you had a look in FPGA editor to see what's going on?
This is where I myself look dim: I did open up the NCD file in the FPGA
Editor. I didn't really know what to do to tell if the right
registering was occurring. All I could see was that all 4 DSP48s were
instantiated together in a little row. I've never used FPGA editor
before. I'm more familiar with PlanAhead for looking at that sort of
thing, but I don't have that on my laptop, my current working platform.
> Is it actually this bit of code that limits the timing?
Well, all I can say is that I don't think so. It could very well be
though, but I've tried writing the VHDL in very different ways, guided
by things I've found in one or two guides to instantiating the DSP48s
in VHDL. Every way I write the VHDL, the same performance is obtained.
The thing is that I can see that the synthesis tool is making some kind
of effort to pipeline the thing.
This is the critical path that comes out of the synthesis report if
this means anything to anyone:
Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
(mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
DSP48:PCIN47->PCOUT47 1 2.363 0.000
mult_inst/Mmult__n00002
(mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
DSP48:PCIN47->PCOUT47 1 2.363 0.000
mult_inst/Mmult__n00003
(mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
(mult_inst/Mmult__n0000_s_69)
FD:D 0.391 mult_inst/Mmult__n0000_0
----------------------------------------
Total 12.320ns (11.786ns logic, 0.534ns route)
(95.7% logic, 4.3% route)
Cheers,
Robin
Reply by ●July 4, 20062006-07-04
"Robin Bruce" <robin.bruce@gmail.com> writes:
> Hi Guys,
>
> I'm having trouble with the following problem:
>
> I'm trying to create a 35x35 signed multiplier from DSP48s, inferring
> pipelining in VHDL by adding registers after the multilplication
> operation as seen below in the VHDL I'm using.
>
> The problem is that when I synthesise, though I can see that the
> synthesiser has noticed that it can shift registers about:
>
> Synthesizing (advanced) Unit <signed_mult_TOP>.
> Found pipelined multiplier on signal <mult_inst/_n0000>:
> - 2 pipeline level(s) found in a register connected to the multiplier
> macro output.
> Pushing register(s) into the multiplier macro.
>
> - 2 pipeline level(s) found in a register on signal <mult_inst/A2>.
> Pushing register(s) into the multiplier macro.
>
> - 2 pipeline level(s) found in a register on signal <mult_inst/B2>.
> Pushing register(s) into the multiplier macro.
>
> the clock rate achieved is still only a meagre 81.171MHz. I'll save my
> half-baked hypotheses for now and see if anyone knows what's up here.
> Any help you can give would be very much appreciated.
>
Only more (potentialy dim) questions I'm afraid:
Have you had a look in FPGA editor to see what's going on?
Is it actually this bit of code that limits the timing?
Cheers,
Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt