I've finaly decided to dump the inouts altogether...
I use buffers to be able to read back the config values and a bit in the
address to decide if I want to read the old value or the computed value.
No ZZZZZs no complicated things and my code is cleaner.
Mike Treseler said:
It's just gates and flops.
This inout thing, I meant. writing inout at one place has too many
repercutions on so many modules of my code is plain bad.
But now, with your help and insights, I've finaly got my stand-alone
component. It handles all the comms and there is no way an outside
component's actions can break it. Zero coupling.
If it's a pc you want to talk to, consider ethernet or usb.
I'm using usb and an ezusb chip in between my spartan and my pc's usb port.
Is there any other way I should know about?
Why not write and sim the guts first?
By guts you mean payload?
It was written first, and simmed. and then I wrote the comms part, and sent
all that thing into the fpga and found out it didn't work as expected. Seems
the comms were luring me into thinking that the info I wrote on the usb port
really reached the payload. so I tried to debug the comms, and found out
(after visiting this NG) I wasn't quite using the inouts like I should
have... or at least that my understanding of what an inout port was false.
This will take longer than you think.
What will?
Adding an I/O interface is really not that big a deal.
well...
being completely a newbie at this sport, it really took me at
least 2 weeks to make it work... while the payload took me about the same
time... And I thought the payload would really be the hard part to get
working.
(Now I have too many slices, my comms + payload is too fat. and maybe once
refined, the resulting payload won't work anymore... But I'm prepared
psychologicaly to face that kind of hazard)
In fpga design, you decouple by writing a sim testbench
that you can quickly rerun after each change, to make
sure nothing got broken.
I saw a testbench posted by someone (you maybe) and I'm very far from being
able to automate anything the way it was done.
But then again, I'm a complete newbie. My main line of work is software
engineering (not embeded) and I 'm trying to achieve parallel computing by
using a fpga for some fast int computation.
Use of variables, functions and procedures instead of straightline code
makes changes less likely to cause unexpected effects.
Someone warned me about those not being such a good idea if comming from the
non embeded software world. I tried to imerse myself into the
component/entity philosophy (at least the way I percieved it) and up until
now the results have been quite encouraging. Something I have to check
though is that too many components embeded into one another don't slow
things down or make the code too fat.
There is no requirement to use components at all except
in testbench code. I prefer to use a minimum number
of processes in a single entity for synthesis.
This makes things as algorithmic as possible.
but I thought the whole point of vhdl was concurent computing instead of
process/serial computing?
And that making components allows us to "divide and conquer", modules by
modules; and also component seemed the nearest thing to an object I could
find.
At some point I had processes and functions and procedures, but I found the
mix wasn't such a good idea (or at least harder to synchronize for the
newbie that I am)... but that was at a time when I knew nearly nothing (less
than now, I mean ;-) ).
You should find a way to start writing and siming some code.
When I'll be a jedi, I'll refine the way I work...
But right now, I need my project to work (there's a payload, a comms
component, a pc side library and the corresponding GUI to load the rbt file
and to control the beast...).
The comms now work fine. the payload works fine under the sim (but I haven't
tested the timings - and don't know how to... there is a huge chapter on
this in the book I use... My approach is try to slow down the computation as
much as possible and see if things work as expected. If so, I raise the Mhz
up untill things start to break. If the speed limit is high enough, I stay
that way. If not, I guess I'll have to switch to siming...)
The pc side library is well under way (it's not packaged yet, but the
various functions are all over my present code), the GUI is functionnal, but
the errors are not correctly handled (ie: if I unplug the fpga board).
It's a prrof of concept thing... Having a board that anyone could use to do
the things we want.
Yes: ethernet, usb, rs232 etc. etc.
Yes there is?
hum... I'm using an spartan fpga... My feeling is that it would be easier to
use dedicated chips (ezusb, max232 etc) for all of those and use the fpga
for data processing. am I wrong there?
but what you say is interesting, I also have a small lcd screen I was
wondering I could use or not. Its controler talks in 19kbps serial. I was
wondering if it was hard (or if the resulting code was big) to have those
two communicate.
How about an output signal named OE?
??
I did use WR and OE (from the example code I got with the ezusb thing), but
don't really know what they mean.
Must be a traditional thing (of the foo/foobar type) from the embeded
world.
You are right about that.
right about what? that I'm wastying my time?? (then yours too, I guess,
sorry sorry)
Or that it is so common? I have two books on the subject and both fly over
the ZZZZs and INOUT in about a page or two.
If they had, VHDL would be much less flexible.
Should Intel start hard-coding Basic or Forth into their uPs
to isolate me from the MOV instruction?
??? I can code in delphi and switch to low level MOV,JPZ etc code whenever I
wish (all I need is to start an asm inline block of code). but it does
provide the high level things I need to write code fast. (I believe that can
be done in C++ too...).
That way I can focus on the result and if I need to look into the small
details of code (to refine things, make the code leaner, faster etc), I can
override his jugdment and tell him how I want things to be done.
Of course the higher the level, the fatter the code...
But take the := in vhdl processes. It's quite magical. Suddenly you're not
talking wires anymore, nor concurrent programming; and the compiler handles
the complexity for you. he translates those high level commands to low level
wirings.
or again, the + - * / so many people use in vhdl. those are high level
notations that do magical things without your knowing... Do you really feel
the langage is less flexible because of the existence of those operators?
you can do without them and write your own primitives if you wish. But
still, I bet most of the time most people use the operator notation instead
of their own cascading muxes (I believe that's the way it's done, right?).
if they decided to have a magical inout_V2, that would take the value of the
last "drive" to have taken place, and some kind of automagic resolution of
conflict when 2 (or more) drive take place at the same time... wouldn't that
be great? it would generate some "micro vhdl code" that we could study and
refine if we want... and you could still do the same thing in your own
precise way... would you really feel restrained or betrayed by the compiler
if that V2 existed?
The point is providing a high level fucntion doesn't have to isolate you
from the inner lower level sub functions.
But that's a philosophic issue... I agree
(And whatever we say, things
are the way they are and we'll have to make do with what we have ;-) ).
Anyway, you've been a great help to solve my current problem(s) and your
inputs where enlightening to say the least.
Thank you for your time,
Mink.