Design analyse methods

[ALuPin]

Dear Sir or Madam,

when tyring a complex FGPA design on real hardware
what possibilities do exist to analyse the design ?
Of course one possibility are debug pins but the problem
is that their availableness is not always given.

Simulation might be a good first step in order to prove
first correct functionality but what if there are
some components which cannot be reproduced my models so
easily?
Are their any tools (for Altera Cyclone FPGA) which allow
to observe the diffent signals live (not simulation!) without having
to route them to output pins (which are of limited number anyway,
apart from that
the timimg may be changed in an unmeant way) ?

Thank you for your information and help.

Best regards

Andre

 

[Ian Poole]

"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0312020511.4194c798@posting.google.com...

Dear Sir or Madam,

when tyring a complex FGPA design on real hardware
what possibilities do exist to analyse the design ?
Of course one possibility are debug pins but the problem
is that their availableness is not always given.

Simulation might be a good first step in order to prove
first correct functionality but what if there are
some components which cannot be reproduced my models so
easily?
Are their any tools (for Altera Cyclone FPGA) which allow
to observe the diffent signals live (not simulation!) without having
to route them to output pins (which are of limited number anyway,
apart from that
the timimg may be changed in an unmeant way) ?

Thank you for your information and help.

Best regards

Andre

So, you have an FPGA on a board and you want to know the value of signals
within that FPGA, but you don't want to use any external pins? Hmmm.

Two sensible choices -
SignalTap - Not used it, but at a guess it uses internal RAM to store
signals, then communicate them via JTAG back to the host PC.
VITAL, or Gate Level simulation. OK, its simulation, but (in theory) it is
the Place and Route tool's view of what it has just placed and routed,
complete with ps accurate delays. You should do a gate level sim anyway,
just in case your design has been broken by one of the tools along the way.


--
Ian Poole, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: ian.poole@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Subroto Datta]

Altera provides the SignalTap II tool to allow monitoring live signals
inside the FPGA. This solution uses the internal RAM. Details of how this
tool can be used are provided in
http://www.altera.com/literature/an/an280.pdf

Hope this helps.

- Subroto Datta
Altera Corp.


"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0312020511.4194c798@posting.google.com...

Dear Sir or Madam,

when tyring a complex FGPA design on real hardware
what possibilities do exist to analyse the design ?
Of course one possibility are debug pins but the problem
is that their availableness is not always given.

Simulation might be a good first step in order to prove
first correct functionality but what if there are
some components which cannot be reproduced my models so
easily?
Are their any tools (for Altera Cyclone FPGA) which allow
to observe the diffent signals live (not simulation!) without having
to route them to output pins (which are of limited number anyway,
apart from that
the timimg may be changed in an unmeant way) ?

Thank you for your information and help.

Best regards

Andre

 

[Vaughn Betz]

As Subroto suggests, SignalTap II best matches what you're asking for,
in that it does not require debug pins.

Something else that may be of interest is SignalProbe. It lets you
bring signals to unused output pins for debugging, without changing
the placement & routing (and hence timing) of the rest of your design.
So it does require debug pins, but it avoids the chaning timing
issues you're worried about.

Vaughn

Altera provides the SignalTap II tool to allow monitoring live signals
inside the FPGA. This solution uses the internal RAM. Details of how this
tool can be used are provided in
http://www.altera.com/literature/an/an280.pdf

Hope this helps.

- Subroto Datta
Altera Corp.


"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0312020511.4194c798@posting.google.com...
Dear Sir or Madam,

when tyring a complex FGPA design on real hardware
what possibilities do exist to analyse the design ?
Of course one possibility are debug pins but the problem
is that their availableness is not always given.

Simulation might be a good first step in order to prove
first correct functionality but what if there are
some components which cannot be reproduced my models so
easily?
Are their any tools (for Altera Cyclone FPGA) which allow
to observe the diffent signals live (not simulation!) without having
to route them to output pins (which are of limited number anyway,
apart from that
the timimg may be changed in an unmeant way) ?

Thank you for your information and help.

Best regards

Andre

 

[Mike Treseler]

ALuPin wrote:

Simulation might be a good first step in order to prove
first correct functionality

Best first, second and third step.

but what if there are
some components which cannot be reproduced my models so
easily?

Inside the FPGA, don't use vendor core generators.
Write your own code that infers what you need.

For memory and other external parts, choose devices
with free models or write some code.
You may not need a very fancy external model to verify
your own synth code.

Once you're done, you can "probe" wherever
you like with sim waveforms, and have the
freedom to make changes fearlessly.


-- Mike Treseler

 

[pl[N0SP4M]apri]

Mike Treseler wrote:

ALuPin wrote:

Simulation might be a good first step in order to prove
first correct functionality


Best first, second and third step.

Especially given the possibility of testing using post-place-and-route
simulation models with back-annotated signals, which include most of the
timing issues that can crop up...

but what if there are
some components which cannot be reproduced my models so
easily?

I'm not sure I've correctly understood this question, but it seems to me
that if you can't test a module in simulation, where you have access to
_all_ the internal signals, you'll have an even harder time doing so
when you only have access to a limited subset... Could you elaborate?
What couldn't be reproduced?

Inside the FPGA, don't use vendor core generators.
Write your own code that infers what you need.

Mike, I'd be interested in hearing why you think this, I'm not sure that
I agree.

Pierre-Olivier
--
-- to email me directly, remove [N0SP4M] from my address --

 

[Mike Treseler]

Pierre-Olivier wrote:

Inside the FPGA, don't use vendor core generators.
Write your own code that infers what you need.

Mike, I'd be interested in hearing why you think this, I'm not sure that
I agree.

This is a trade-off of device utilization
verses independence and ease of simulation.

There will always be things you can't infer
from code. I'm happy to leave those things
unwired.

-- Mike Treseler

 

[Muthu]

Hi,

As in SignalTab from Altera, is there any way of doing similar in XILINX FPGAs?

Regards,
Muthu