Bummer. I used this on the ATA F board design, but it was not done
using the CASPER toolflow. Maybe a "small" modification to the
CASPER toolflow to change this to a warning rather than an error
would make it workable for you.
Dave
On May 11, 2010, at 7:31 , Rick Raffanti wrote:
Correct, it doesn't work. You can attach the constraints in
Verilog (eg, (* LOC = "B11" *)), and it compiles in the Xilinx
IDE, but the casper tools tell me that all the ports need to be
connected to GPIO blocks, or something.
My next attempt is to simply use the gpio yellow block as a bunch
of wires, if I can figure out how to select which ZDOK pairs I want.
Rick
Henry Chen wrote:
Hi Dave, Rick,
There are constraints in Verilog for this (IOB=TRUE and LOC), but I
suspect that the tools may have trouble passing the port connectivity
upstream. Since the Simulink design gets used as a sub-component of
a larger project, all of the connectivity to external and inter-
module
ports get passed upwards to the top level for wiring. I guess this is
one of the primary purposes of the toolflow and the yellow blocks.
Without the directives and markers of a yellow block, these inputs
might
be left floating and cause the compiler to freak out.
I've never tried to define external ports without propagating them to
the top level, but it's probably worth a try.
Thanks,
Henry
On 5/10/2010 8:53 PM, David MacMahon wrote:
Hi, Rick,
I know that the Xilinx synthesis tool (xst) recognizes the LOC
and related constraints as VHDL attributes and propagates them to
downstream tools. I believe there is a Verilog analog.
Dave
On May 10, 2010, at 16:45 , Rick Raffanti wrote:
Hi Henry,
Thanks, I get that. But I've also found that the "black box"
procedure that Jack Hickish pointed me to seems to work really
nicely: I can put some Verilog in a black box, connect up signal
sources and sinks, and simulate it without any Matlab "m
language" fol-du-rol. So now I have a small chunk of Verilog
which does what I want, and I can simulate it, and its input
side is clocked by a ZDOK pair, and its output side is clocked
by the system clock (which the "black box" process connects
up). If I could only connect it to the &%$#)~! pins I'd be done!
Rick
Henry Chen wrote:
Hi Rick,
That's actually a pretty good question. A not-so-good answer is
that
you'd make a yellow block when existing yellow blocks don't
provide
all of the functionality you need ;)
Basically, Simulink/SysGen is very poorly suited for things
that are
not well abstracted by pipelined logic in a single clock
domain. So
anything dealing with clock management, crossing different clock
domains, low-level I/O constraints, asynchronous delay paths, etc.
would likely need its own yellow block.
For a lot of basic interface needs, using the GPIO yellow block
while
clocking the whole FPGA (including the I/O data) with usr_clk
might
be sufficient.
Thanks,
Henry
On 5/10/2010 4:16 PM, Rick Raffanti wrote:
At the risk of looking like a knucklehead:
I'm working through the "How to make a yellow block" memo, and
it seems complicated. But it seems like the whole purpose, at
least in my case where I have a digital input, not an ADC, is
simply to define the pin assignments of my HDL. So my
question is "Why to make a yellow block?".
Can anyone explain?
Many thanks.
Rick
