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
