EDK : FSL macros defined by Xilinx are wrong

[rickman]

On Jan 22, 2:11 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

rickman <gnu...@gmail.com> wrote:

(snip, someone wrote)

adding capacity and reducing impedance is not an issue,
I can use larger diameter wires at will
and my collection of capacitors is still growing
The wire diameter has very little to do with the impedance.  

Wire diameter is related to inductance, though.
And inductance is related to impedance...

Just don't even go there. For all practical purposes, changing the
diameter will have no noticeable effect in this situation. Don't
encourage the guy!

Any capacitor you use has impedance.  You can see this
very clearly if you look at the impedance-frequency
curves for the parts.  The resonant frequency tells you the
frequency at which the capacitive and inductive impedance
are equal.  As the frequency continues to increase
the impedance rises.  For a high speed design the impedance of the cap
becomes significant at frequencies that are important.  That is why
power planes are used.  They provide a low impedance at frequencies
into the GHz range.

-- glen

 

[whygee]

Hi again

rickman wrote:

On Jan 21, 9:15 pm, whygee <why...@yg.yg> wrote:
Hi Rick !
rickman wrote:
Have you considered a different family?
I'm already satisfied with what I got from Actel
("it works and has what i want")
and I bet that any issue I'll have with SDRAMs
will not be related to the FPGA family itself,
snip
I am of the opinion that with the top three FPGA vendors, Xilinx,
Altera and Lattice, there is not a lot to "evaluate".
that is one of my worries, an old one indeed.

lack of choice, capture of the design into a vendor's "ecosystem"
and the long-term consequences. That's why I was so reluctant
to their products during so many years. Fortunately,
things change, even me.

Each vendor has
at least one high end line that is fast, dense and has lots of bells
and whistles. They also have at least one line of economy chips that
are cheap and yet still very capable. Unless you are planning to push
the limitations of any of these chips, what is there to evaluate?
how fast, easy, cheap and not alienating their tools are.

I recently did a review of the market and I'm still not joyful.
However surprises may happen and I want to be there when it happens.

I didn't get the impression that this is about a product,
not yet. There are too many variables to take into account,

and my money making activities are often more than satisfied
with an under-used PIC. I prepare for the distant, better future.

so if you are
just using this as a learning tool, what basis do you have for
evaluation? What is your criteria?
I guess that you will not like my answer, but what about

"I see if I like it, if it "speaks" to me, if I understand its perspective..."
Yes, it's completely subjective but sometimes it's not possible
to name coherent criteria when they collide /but/ there is still
freedom to balance them.

I know that I would choose the
device that is easiest to prototype with and later worry about that
device I want to use in a product.
prototyping ease is essential.

then there are countless other... parameters.

BTW, when you say you have no support tools for the Altera device, I
think i told you that the Altera FPGA tools are available free.
you did.

I just wasn't happy with Altera's policies and other details
so it put this issue on hold. There are other vendors to "evaluate"
and that have less constraining methods.

You can clock an SDRAM as slow as you want to some
point. You do have to provide a periodic refresh cycle unless you are
doing that in software. But the clock speed won't have much to do
with the SI and power decoupling issues.

afterthought

And if the SDRAM can be clocked as slowly as one wants,
then I could even "prototype" the SDRAM interface
with "bitbang"-like software, and then move slowly from
soft to VHDL as it starts to work...

That will be interesting. There are limits to how slow it can run,
check the data sheet.
of course.

The initialization is not all that bad, at
least if you are using SDRAM. I did one of those some 10 years ago.
I just made a FSM and it worked the first time.
Either you're lucky, or you're very good, or SDRAM is less

complex than I thought ;-)

I did find a lot of
good app notes and data sheets at Micron Semi. I don't know if they
are still available. I have them in print form. 8^*
I'll go hunting datasheets when I feel courageous enough.

Meanwhile, I decided to make a major rework of the yasep.org website,
my JavaScript vice is biting me hard at this moment :-/

If you are interested in MISC processors,
comp.lang.forth is a good place.

However YASEP is not MISC, it's just "small"
But Forth and the likes are definitely worth caring.

YASEP... Yet Another Small Embedded Processor? I feel the same way
about mine.
that's funny

is it available online ? do you have any documentation about it ?

I designed a CPU some 8 years ago based on the Forth
model. It turned out remarkably similar to Bernd Paysan's b16, but
with very different instruction format. From the work I have done, it
appears that the data path will dominate the size of the design. Then
the efficiency is determined by how well your instruction set uses
parallelism in the data path.
That does not scare me...

There is a lot to learn by working with someone else's design.
sure.

I guess I am saying you can learn a lot more from someone else than you
can by yourself.
I have examined countless architectures. Besides the PCs that I know

quite deeply, I have many other machines and families, either as
chips, machines, book, archives... I won't list them.
I have learnt a lot in the past 15 years but even with VHDL simulators,
I was missing real hardware interactions.
And experience is better when you get it yourself, get your own fingers
burnt etc.

programming cable is not a lot of money.
I consider making my own,
once I have time and all the SW issues solved.
I'll let this whole can of worms alone.
One more reason to let Altera at the bottom of my priority list.

There is another thread about
using Windows or more specifically, Vista. It is getting long winded
and the more radical elements are coming out.
The Vista thread is interesting as it shows several cultural drifts.

I do my best to keep my dependence from M$ as low as possible.

I'm now seriously considering a SPI-only interface and
I've found some platforms that allow one to avoid proprietary
JTAG interfaces. And a SPI interface is as easy as bitbanging
on the parallel printer port on any PC (even recent ones,
just not from the local supermarket).

It looks like a "dirty hack" with 25mil wires from IDE cables
is the fastest, cheapest and easiest way now.
Maybe it won't work but it will probably help me
understand and get a first foot in the sh^Wmatter...

Man, you *are* a masochist! Good luck.
thanks ;-)

I'll take pictures of whatever comes out, whenever it does.
I'd like to do something basic and easy, tonight.

http://yasep.org
I took a look. I'm just curious, why are you designing your own processor?
Some answers are there : http://yasep.org/docs/vsp05.txt (this is OLD).

Maybe http://yasep.org/docs/yasep.html is not enough and should be
supplemented. However, contrary to the F-CPU era, I now prefer
to design, experiment, etc. instead of constantly justifying myself.
It always takes too much time, energy etc. and in the end,
everyone is sour. I don't want this, so there is not even a forum
or a mailing list that will distract me. It's personal.

And Usenet is a wild weird place too, and I don't want to troll.

I assume you are aware that there are literally dozens of
other processors out there... hence the name.
then... why are there "only" dozens ?

and why did you design yours ?
and why why...
too many questions, too little fun :-/

best regards and thanks for all the insights,

Rick
yg

--
http://ygdes.com / http://yasep.org

 

[whygee]

John Adair wrote:

I'm not sure if you just want a module with 2.54mm pins or a
development board with SDRAM but we can offer both.

For a module we dil header style SDRAM modules. These are out of stock
just now but should be available in a few weeks. These modules are
aimed at our Raggedstone range range of boards.

In the development board area we have Darnaw1 http://www.enterpoint.co.uk/moelbryn/darnaw1.html
which currently has 128Mbit SDRAM on as standard but we have a batch
going through shortly where we are looking at increasing the SDRAM and
SPI Flash sizes on the XC3S1600E versions.

There is also a new product coming that is very much aimed at
microprocessor applications based in FPGA and that will have 256Mbit
SDRAM in a X32 organisation and has capability to go to 512Mbit. I'm
expecting to announce this properly in 3-4 weeks time when have run
some tests on it.

thank you, i'll have a look

John Adair
Enterpoint td.
YG

--
http://ygdes.com / http://yasep.org

 

[whygee]

hi !

rickman wrote:

Just don't even go there. For all practical purposes, changing the
diameter will have no noticeable effect in this situation. Don't
encourage the guy!
hummm...

not even to test the principle before making a PCB ?

--
http://ygdes.com / http://yasep.org

 

[glen herrmannsfeldt]

whygee <whygee@yg.yg> wrote:

rickman wrote:
Just don't even go there. For all practical purposes, changing the
diameter will have no noticeable effect in this situation. Don't
encourage the guy!
hummm...
not even to test the principle before making a PCB ?

I agree that one should know what one is doing before
designing a PC board. Believing that width doesn't matter
and using very narrow traces isn't a good start, though.

-- glen

 

[Symon]

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:h68hn4d2198akklhhj4327ujkshmsr2lej@4ax.com...

On Thu, 22 Jan 2009 07:29:49 -0600, krw <krw@att.zzzzzzzzz> wrote:

We're not really sure how it gets out. The FPGA feeds dacs clocked at
128, which feed lowpass filters, output amps, and the connectors.
We're seeing lines as big as -45 dBm coming out the connectors. If you
wave a spectrum analyzer probe around the board, the junk is most
intense just over the FPGA. Some weird points: the lines are at
different frequencies on the two different boards, even though the
fpga's are very similar; one board tends to have lines in pairs, a
couple of MHz apart; we can almost swear that once we saw the whole
spectral forest shift around, in one instant on one board, when
nothing else was going on.

It would be fun to really investigate the cause of this, but all we
have time to do is fix it.


John

John,

The Xilinx tools sometimes add in extra clocks to fix problems the NBTI
listed in the errata. Especially the MGTs and the DCMs. Might be that. You
can prolly turn that stuff off with an environment variable to see if the
junk goes away.
HTH., Syms.

 

[John Larkin]

On Fri, 23 Jan 2009 11:03:42 -0000, "Symon" <symon_brewer@hotmail.com>
wrote:

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:h68hn4d2198akklhhj4327ujkshmsr2lej@4ax.com...
On Thu, 22 Jan 2009 07:29:49 -0600, krw <krw@att.zzzzzzzzz> wrote:

We're not really sure how it gets out. The FPGA feeds dacs clocked at
128, which feed lowpass filters, output amps, and the connectors.
We're seeing lines as big as -45 dBm coming out the connectors. If you
wave a spectrum analyzer probe around the board, the junk is most
intense just over the FPGA. Some weird points: the lines are at
different frequencies on the two different boards, even though the
fpga's are very similar; one board tends to have lines in pairs, a
couple of MHz apart; we can almost swear that once we saw the whole
spectral forest shift around, in one instant on one board, when
nothing else was going on.

It would be fun to really investigate the cause of this, but all we
have time to do is fix it.


John

John,
The Xilinx tools sometimes add in extra clocks to fix problems the NBTI
listed in the errata. Especially the MGTs and the DCMs. Might be that. You
can prolly turn that stuff off with an environment variable to see if the
junk goes away.
HTH., Syms.

Yeah, there seem to be many extra clocks inside; this is an XC3S400.
One other interesting thing: on one of the units, if we power cycle
it, it comes up, randomly, with one of two distinct spectral patterns
which have nothing in common but the big 128 and 256 MHz lines. All
the junk pops up the instant the chip is configured.

All the various birdies must be somehow phaselocked, or maybe just
injection locked, to the 128 MHz clock; they couldn't be so
rock-stable without an external frequency reference. I suppose that's
good... less random jitter issues.

We were conjecturing that internal plls and dcms that we don't use may
be wandering off and doing things on their own.

John

 

[rickman]

On Jan 22, 9:07 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

whygee <why...@yg.yg> wrote:
rickman wrote:
Just don't even go there. For all practical purposes, changing the
diameter will have no noticeable effect in this situation. Don't
encourage the guy!
hummm...
not even to test the principle before making a PCB ?

I agree that one should know what one is doing before
designing a PC board. Believing that width doesn't matter
and using very narrow traces isn't a good start, though.

We are not talking about traces on a PCB, we're talking about the
diameter of a wire in free space. On a PCB the width affects the
capacitance and therefore greatly affects the impedance. In free
space it has much less effect.

I told Whygee to limit the length of the wires in the power circuit
and his reply was that he would keep the impedance of the power wires
down by using fat wires. With the power loop being a literal loop in
the air, the length of the wire will by far outweigh the diameter of
the wire in determining the impedance of the circuit. I doubt that
you would ever be able to measure the difference in impedance from
changes in the width of the wires.

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip)

We are not talking about traces on a PCB, we're talking about the
diameter of a wire in free space. On a PCB the width affects the
capacitance and therefore greatly affects the impedance. In free
space it has much less effect.

Compared to a PC trace with a ground plane, yes.

But if you have a wire of a given length and distance from
other wires through space and you need to reduce its impedance,
the only way is to increase the diameter.

I told Whygee to limit the length of the wires in the power circuit
and his reply was that he would keep the impedance of the power wires
down by using fat wires. With the power loop being a literal loop in
the air, the length of the wire will by far outweigh the diameter of
the wire in determining the impedance of the circuit. I doubt that
you would ever be able to measure the difference in impedance from
changes in the width of the wires.

Assuming that the inductance is much more important than series
resistance, probably true. It isn't hard to get small enough
that resistance dominates, though.

-- glen

 

[rickman]

On Jan 24, 4:21 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

rickman <gnu...@gmail.com> wrote:

(snip)

We are not talking about traces on a PCB, we're talking about the
diameter of a wire in free space.  On a PCB the width affects the
capacitance and therefore greatly affects the impedance.  In free
space it has much less effect.

Compared to a PC trace with a ground plane, yes.

But if you have a wire of a given length and distance from
other wires through space and you need to reduce its impedance,
the only way is to increase the diameter.  

You need to consider context. There is nothing that Whygee can do
with the width of his wires that will make a noticable difference in
the way the free space wired SDRAM chip will work, other than possibly
support it better.

I told Whygee to limit the length of the wires in the power circuit
and his reply was that he would keep the impedance of the power wires
down by using fat wires.  With the power loop being a literal loop in
the air, the length of the wire will by far outweigh the diameter of
the wire in determining the impedance of the circuit.  I doubt that
you would ever be able to measure the difference in impedance from
changes in the width of the wires.

Assuming that the inductance is much more important than series
resistance, probably true.  It isn't hard to get small enough
that resistance dominates, though.

That makes no sense to me. He could use 30 gauge wire and still not
have *any* noticeable resistance in this circuit. What sort of
circuit are you picturing?

Rick

 

[-jg]

Thanks for the useful tips; it seems the primary approach is to "stretch"
the signals of interest into fast elements like shift registers and/or carry
chains, and then count these up at some leisure later (how?). That sounds
like it takes a lot of resources (e.g., 16 ticks per slice if I use a
SRL16E). This could explain why some of the papers I've glanced at seem to
take pretty much an entire chip to make a couple of these high-end delay
measuring devices.

The highest precision ones capture a delay line, and then decode the
edge position later, to decide how many delay elements were used.
Of course, this also needs a calibrate action, so one method is to
interleave two
delay lines, one is doing a CAL whilst the other measures - you can
use
a lot of elements doing this, but they are cheap in a fpga.

For now, since it seems feasible to run a small (8 bit)
counter at 204.8 MHz, I'll try that route. 4.883 ns of precision is about
1.5 meters when you multiply by c, so that's still useful to me. Once I get
the basic structure figured out I can look at speeding it up. Today I got
the input logic figured out (what signal is my start condition, and what is
my stop). Since I'm using these signals to calibrate out differences between
identical bitstreams on separated boards inside a common chassis, the
differential delays inside the logic should mostly wash out.

Don't forget most FPGAs allow multiple phase clocks, so you can
duplicate this 4 x on 4 phases, and compare the 4 answers

-jg

 

[nntpman68]

Hi,

I assume, you found already the solution, as the post is quite old.

If not.
You should create a dualport RAM with the quartus software and
instantiate it. (It would be a synchronous RAM though and you had to
change your design a little)
Hnadwritten RAMs work only for small RAMs.

bye

N

Jukka Marin wrote:

Hi,

I started learning FPGA's and Verilog and seem to run into problems every
day

I'm trying to use dual-port RAM for buffering data between a serial link
and a 32-bit CPU bus. I wrote two separate always blocks, one which
receives data from the serial link and writes it in RAM and another one
which talks to the CPU bus and allows reading of the RAM.

When I try to compile this design (using quartus ii), the compiler "never"
finishes and I believe it's trying to build the RAM array out of logic
gates. If I make the RAM small enough, the compiler succeeds (although
it takes a long time).

I did a similar thing for serial link transmission and it worked as expected
(and the compiler used real RAM for the buffer, not logic gates).

Is it wrong to access the same memory in two separate always blocks? The
serial link and the CPU bus are independent and the bus has no clock, so
I'm trying to make an async design. I'm getting no error messages about
RAM from the compiler, so I'm not sure what I'm doing wrong. (Quartus II
is usually pretty verbose, complaining about everything from unused pins
to the color of my socks, but this time it isn't helping at all.)

I would try putting the RAM stuff inside one always block, but it seems a
bit difficult to do.. (or, I still can't think FPGA - my brain always
seems to enter software mode when opening a text editor).

I'd appreciate pointers or examples which would get me unstuck. ;-)

Thanks,

-jm

 

[KJ]

My question is simple, is there any other method to build a modulo-10
counter from CB4CLE modules or I can simply ignore the warning?

Very easy...write the code for a modulo 10 counter in VHDL or Verilog and
stop trying to use vendor specific widgets like CB4CLE that don't do what
you want them to do anyway.

....snippet of VHDL example...

signal Count: natural range 0 to 10;
....
Modulo_10_Counter : process(Clock)
begin
if rising_edge(Clock) then
if (Reset = '1') then
Count <= 0;
elsif(Clock_Enable = '1') then
if (Count = 9) then
Count <= 0;
else
Count <= Count + 1;
end if;
end if;
end process Modulo_10_Counter;

Kevin Jennings

 

[KJ]

my tool warns me that
there may be a problem due to clock skew, because the clock is being
generated after a combinational network (two levels of AND gates to detect
when the counter reaches 10).

Forgot to address this in the earlier post. This warning indicates that
you're not using a synchronous design process (because you're making gated
clocks) which is almost without exception a very big mistake in FPGAs. The
warning should not be ignored, because it means that your design is likely
to not work reliably (like, it works when it is first turned on and then
stops working later...or just the opposite). In any case, the VHDL code I
posted in previously addresses this point as well...but assumes that the
signal 'Clock' is not generated by any logic of any sort (i.e. it comes from
an input pin that comes from a crystal or oscillator or is the output of a
PLL).

KJ

 

[Xin Xiao]

Thanks, but I have to do it with schematics......

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:B3UBl.3614$im1.441@nlpi061.nbdc.sbc.com...

My question is simple, is there any other method to build a modulo-10
counter from CB4CLE modules or I can simply ignore the warning?


Very easy...write the code for a modulo 10 counter in VHDL or Verilog and
stop trying to use vendor specific widgets like CB4CLE that don't do what
you want them to do anyway.

...snippet of VHDL example...

signal Count: natural range 0 to 10;
...
Modulo_10_Counter : process(Clock)
begin
if rising_edge(Clock) then
if (Reset = '1') then
Count <= 0;
elsif(Clock_Enable = '1') then
if (Count = 9) then
Count <= 0;
else
Count <= Count + 1;
end if;
end if;
end process Modulo_10_Counter;

Kevin Jennings

 

[Jonathan Bromley]

On Sun, 5 Apr 2009 23:42:12 -0700 (PDT), goouse@twinmail.de wrote:

Ok, you get this warning about possible dangers arising from clock
skew.
This is definitly true, and would affect your design if you would play
in the X- MHz league.
But for your 10Hz design you probably could have 64bit combinatorical
multipliers in your datapath without being bothered by clock skew
problems.

OUCH - dangerous myth... as Eilert knows well, I hope.

Clock skew is likely to lead to hold time violations,
which break the design's functionality on EACH INDIVIDUAL
clock edge. Hold problems are not related to the time
between clocks, and cannot be fixed by running the clock
more slowly.

(Actually, some logic between your FFs would be
very useful in this case.)

Yes; hold-time fixup. Some FPGA tools already do this for you
to some extent.

For a small, slow design, the message is clear:
USE CLOCK ENABLES. Get your divide-by-10 circuit to
generate a synchronous pulse that is true for 1 cycle
of the 10Hz clock, and false for 9 cycles. Use that
pulse as the clock enable for any logic that you want
to run at 1Hz. Use the single, common 10Hz clock
as the clock input for every flip-flop in the design.
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

On Apr 5, 2:16 am, "Xin Xiao" <n...@no.com> wrote:

Hello, my question is I'm making a modulo-10 counter using a CB4CLE counter
(http://www.xilinx.com/itp/xilinx6/books/data/docs/lib/lib0080_48.html) and
some logic gates. I am making a modulo-10 counter because I need a 1 Hz
clock for my design (the clock input to the counter is a 10 Hz signal). The
problem is that, when I implement my design to a FPGA, my tool warns me that
there may be a problem due to clock skew, because the clock is being
generated after a combinational network (two levels of AND gates to detect
when the counter reaches 10).

My question is simple, is there any other method to build a modulo-10
counter from CB4CLE modules or I can simply ignore the warning?

Thank,

Hi Xin,
as pointed out by KJ it is not a wise idea not to use the global clock
nets for clock signals.
However it's very tricky to do so with signals created by your own
logic.
But there is a well working solution to your problem.

Build your modulo 10 counter so, that it generates a some kind of
ripple signal that is active for only one 10Hz period.
Use this signal as a Clock Enable for all the FFs that shall run with
1Hz. The Clock for these FFs is your 10Hz Master Clock.

There are papers available, e.g. from xilinx, that discuss this method
in detail.
____
Truly, schematic input is not the method of choice for designing FPGA
logic, but it's not your fault that you are forced to use it.
If you are a student, schematics are helpful to understand digital
logic. But if that task is mixed up with understanding how FPGAs work
it is like learning to walk during an olympic sprinting competition.

_____
One more comment :
Ok, you get this warning about possible dangers arising from clock
skew.
This is definitly true, and would affect your design if you would play
in the X- MHz league.
But for your 10Hz design you probably could have 64bit combinatorical
multipliers in your datapath without being bothered by clock skew
problems.
Data would be stable way loooong before the next clock edge.
(Actually, some logic between your FFs would be very useful in this
case.)
There's a very good article in the english wikipedia about Clock Skew.
Read it for further understanding.

Have a nice synthesis
Eilert

 

[Dave Wilson]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:4g4it4d9ah49jmotmo9btar8lmd8qoa3cm@4ax.com...

On Sun, 5 Apr 2009 21:55:21 +0200, "Xin Xiao" wrote:

Thanks, but I have to do it with schematics.....

Oh dear. Why?

Basic Metalwork course, Lab 1:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You are given a piece of steel approximately
5cm x 5cm x 5cm. Your task is to construct
a steel cylinder, of diameter 3cm and length
4cm, without using a lathe. Marks will be
deducted for any evidence that you borrowed
your friend's CNC milling machine. Extra
credit is available for completing the task
using tools made only from elk antlers.

--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

????
If he was using Altera Quartus schematic then it would take less than 10
seconds using the LPM_COUNTER wizard - about 100 times faster than using
crap VHDL.

 

[Jonathan Bromley]

On Mon, 6 Apr 2009 17:03:28 +0100, "Dave Wilson" wrote:

????
If he was using Altera Quartus schematic then it would take less than 10
seconds using the LPM_COUNTER wizard - about 100 times faster than using
crap VHDL.

That's the purest humbug. You can't even START the wizard in
ten seconds. Then you have to wade through a gazillion
dialogs. Then you have to drop the stupid thing on a sheet
and wire it up. Any wizard, no matter how clever, must
guide the user through all the choices that the same user
could have made with a few keystrokes of text.

Give me text any day. Verilog, VHDL, even PALASM if you
really must torture me. But spare me the schematics.
They have their uses when doodling on restaurant napkins,
and maybe for some kinds of top-level block-stitching,
but not for anything much else.

Schematics live in my head, as a thinking tool, and
occasionally leak out on to paper as a tool for communicating
with myself or with fellow humans. They are a lousy design
entry tool. And that's even before you start to deal with
the general crumminess of most schematic capture packages,
where tools for ripping and re-numbering buses are
palaeolithic, and re-use means working out how to bring
up impenetrable property sheets instead of simply patching
and commenting the generics on VHDL components.

I guess we'll have to agree to differ, but I gave up
serious use of schematics a decade ago and I don't miss
them even a tiny little bit.
--
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Mark McDougall]

Jonathan Bromley wrote:

I guess we'll have to agree to differ, but I gave up serious use of
schematics a decade ago and I don't miss them even a tiny little bit.

Not to mention problems with re-use, portability to other vendors, and
version control software issues (diff anyone?).

Serious PL work just isn't done in schematics.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266