Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 153900

Article: 153900
Subject: Replacement for XC4005E
From: Terry Brown <terry@invalid.invalid>
Date: Thu, 28 Jun 2012 17:23:08 +0100
Links: << >>  << T >>  << A >>
We've been using the venerable XC4005E FPGA from Xilinx for many years 
now in a bunch of products.  However the variant we use has now been 
discontinued, and although we can get sufficient quantities to satisfy 
our quite low (<100 per year) demand it's time to change some of the 
stuff out and redesign where appropriate.  Sadly that'll also mean 
upgrading our toolchain too, but needs must.

Can anyone suggest something similar, not necessarily from Xilinx?  We 
don't do anything much with them, just interface to PC104 (ISA) bus and 
present a bunch of registers in IO space, or stick some custom low-speed 
logic in them, or do address decoding for external chips.

The biggest draw for the 4005 was the 144pin quad flat package which was 
easy on our hand assembly process and the user IO count of 110-ish pins 
which we need to keep or maybe exceed a bit.  Internal logic was always 
drawn as circuits using ViewDraw, don't need any fancy HDL stuff here 
(and in fact could do without the learning curve anyway).  Oh, and also 
5V IO would be neat (ISA bus interface) but 3.3V logic also would be 
good, because it's getting hard to find a bunch of things in 5V these days.

Any suggestions?

TIA
Terry

Article: 153901
Subject: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 28 Jun 2012 11:14:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::=
{ sequential_statement }

sequential_statement ::=
wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::=
{ combinatorial_sequential_statement }

combinatorial_sequential_statement ::=
assertion_statement	-- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Article: 153902
Subject: The definition of combinatorial process?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 28 Jun 2012 11:21:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

The debute focus later turns to which is the best way to code: either one sequntial process or two process method, one combinarotial process and one sequential process.

The strange thing is that I cannot even find the word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a clock statement in one of my thinking. 

process_statement_part ::=
{ sequential_statement }

sequential_statement ::= 
wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::=
{ combinatorial_sequential_statement }

combinatorial_sequential_statement ::= 
assertion_statement	-- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Am I right?

Weng

Article: 153903
Subject: Re: Replacement for XC4005E
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 28 Jun 2012 13:46:58 -0500
Links: << >>  << T >>  << A >>
Terry Brown wrote:

> We've been using the venerable XC4005E FPGA from Xilinx for many years
> now in a bunch of products.  However the variant we use has now been
> discontinued, and although we can get sufficient quantities to satisfy
> our quite low (<100 per year) demand it's time to change some of the
> stuff out and redesign where appropriate.  Sadly that'll also mean
> upgrading our toolchain too, but needs must.
> 
> Can anyone suggest something similar, not necessarily from Xilinx?  We
> don't do anything much with them, just interface to PC104 (ISA) bus and
> present a bunch of registers in IO space, or stick some custom low-speed
> logic in them, or do address decoding for external chips.
> 
> The biggest draw for the 4005 was the 144pin quad flat package which was
> easy on our hand assembly process and the user IO count of 110-ish pins
> which we need to keep or maybe exceed a bit.  Internal logic was always
> drawn as circuits using ViewDraw, don't need any fancy HDL stuff here
> (and in fact could do without the learning curve anyway).  Oh, and also
> 5V IO would be neat (ISA bus interface) but 3.3V logic also would be
> good, because it's getting hard to find a bunch of things in 5V these
> days.
How much logic are you putting in there?  There is the XC9500XL series,
all 3.3 V, and the CoolRunner series that needs two voltages.
For more logic, there is the Spartan 3A or 3AN series, VERY affordable,
and you can still have 3.3 V I/O on them.  Almost certainly you could
use the smallest, the XC3S50A(N) to replace the 4005.

But, from the sounds of it, the CoolRunner or XC9572XL would cover
the logic needed.  For wide address comparators, the CPLD architecture
actually works a lot better, since it is composed of 18-input gates.

Jon

Article: 153904
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 28 Jun 2012 20:11:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
Weng Tianxiang <wtxwtx@gmail.com> wrote:
> The following topic may be one of the longest debate in vhdl group:
> http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

I know verilog much better than VHDL, but ...

> The debute focus later turns to which is best way to use one
> sequential process or two combinarotial process and sequential
> process.

> The most important and strange thing is that I cannot even find the
> word "combinarotial" in VHDL-2002 specification.

It might not be related to a VHDL specification.

> I want to grammarly define a combinatorial process which cannot have a
> clock statement in one of my thinking.

Well, yes, but you probably also shouldn't have any type of latch,
such as you might build out of NAND gates. But some kinds of
feedback loops might be allowed. (An always interesting question is
the end-around carry in ones-complement adders.)

I will guess, then, that in some cases it isn't possible to prove
that a given logic block is, or isn't, combinatorial.

-- glen


Article: 153905
Subject: Re: ISERDES2 divide factor
From: jonpry@gmail.com
Date: Thu, 28 Jun 2012 14:47:40 -0700 (PDT)
Links: << >>  << T >>  << A >>

For posterity.=20

This actually does work in hardware. Although I had to implement my own bit=
slip in addition to the builtin one. I suspect it suffers from the same pro=
blem as all Xapp1064 receivers. Ie data corruption if the IDELAY phase shif=
t crosses from -180deg to +180deg but that is a whole different animal. 

Article: 153906
Subject: Re: Replacement for XC4005E
From: j.m.granville@gmail.com
Date: Thu, 28 Jun 2012 17:05:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 29, 2012 4:23:08 AM UTC+12, Terry Brown wrote:
>... IO count of 110-ish pins  which we need to keep or maybe exceed a bit.  
>  Oh, and also  5V IO would be neat (ISA bus interface)...

 Getting that in a single package will be tough.  Is two OK ?
Lattice do 144 pins, but come up short on reaching 110 i/o.

 A better sweet spot is 100 pins, which includes Atmel ATF1508ASL/ASVL family, which do native single supply 5V operation.
 100 pins also opens more choices from Lattice, and even Cypress PSoC.

For simple IO / decode tasks, then Atmel WinCUPL would work well. 
Small and Fast, compiles simple boolean equation entry.

-jg


Article: 153907
Subject: Re: The definition of comnatorial prcess?
From: Alan Fitch <apf@invalid.invalid>
Date: Fri, 29 Jun 2012 01:50:08 +0100
Links: << >>  << T >>  << A >>
On 28/06/12 21:11, glen herrmannsfeldt wrote:
> Weng Tianxiang <wtxwtx@gmail.com> wrote:
>> The following topic may be one of the longest debate in vhdl group:
>> http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&
> 
> I know verilog much better than VHDL, but ...
> 
>> The debute focus later turns to which is best way to use one
>> sequential process or two combinarotial process and sequential
>> process.
> 
>> The most important and strange thing is that I cannot even find the
>> word "combinarotial" in VHDL-2002 specification.
> 
> It might not be related to a VHDL specification.
> 
>> I want to grammarly define a combinatorial process which cannot have a
>> clock statement in one of my thinking.
> 
> Well, yes, but you probably also shouldn't have any type of latch,
> such as you might build out of NAND gates. But some kinds of
> feedback loops might be allowed. (An always interesting question is
> the end-around carry in ones-complement adders.)
> 
> I will guess, then, that in some cases it isn't possible to prove
> that a given logic block is, or isn't, combinatorial.
> 
> -- glen
> 

The definition I always use for combinational logic is

"The steady-state value of a combinational logic function is purely
defined by boolean logic functions of the steady state value of the inputs."

This implies no memory (state).

VHDL, as a modelling language, allows you to describe such behaviour,
but it isn't defined in the language.

A different approach has been taken in SystemVerilog, where keywords
always_comb, always_latch, and always_ff have been introduced to allow
the designer to describe design intent in the simulation model.

VHDL just does whatever you tell it to, it's up to you to tell it to do
"the right thing" with regard to the hardware you want to model.

regards
Alan


-- 
Alan Fitch



Article: 153908
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 29 Jun 2012 01:09:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
Alan Fitch <apf@invalid.invalid> wrote:

(snip, I wrote)
>> I know verilog much better than VHDL, but ...
 
>>> The debute focus later turns to which is best way to use one
>>> sequential process or two combinarotial process and sequential
>>> process.
 
(snip) 
>>> I want to grammarly define a combinatorial process which cannot have a
>>> clock statement in one of my thinking.
 
>> Well, yes, but you probably also shouldn't have any type of latch,
>> such as you might build out of NAND gates. But some kinds of
>> feedback loops might be allowed. (An always interesting question is
>> the end-around carry in ones-complement adders.)
 
>> I will guess, then, that in some cases it isn't possible to prove
>> that a given logic block is, or isn't, combinatorial.

> The definition I always use for combinational logic is

> "The steady-state value of a combinational logic function is 
> purely defined by boolean logic functions of the steady state 
> value of the inputs."

> This implies no memory (state).

Sounds good to me. As far as I know, though, there isn't
any simple test for it.

Also, no guarantee on how fast the output gets to where
it is suppose to be.

> VHDL, as a modelling language, allows you to describe 
> such behaviour, but it isn't defined in the language.

> A different approach has been taken in SystemVerilog, 
> where keywords always_comb, always_latch, and always_ff 
> have been introduced to allow the designer to describe 
> design intent in the simulation model.

So far I haven't been interested in SystemVerilog. 

> VHDL just does whatever you tell it to, it's up to you 
> to tell it to do "the right thing" with regard to the 
> hardware you want to model.

-- glen

Article: 153909
Subject: Re: The definition of comnatorial prcess?
From: goouse99@googlemail.com
Date: Fri, 29 Jun 2012 00:13:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
> The following topic may be one of the longest debate in vhdl group:
> http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd=
78a33d1dae/3de3fe8ea3eec9ad?hl=3Den&q=3Dcombinatorial&lnk=3Dol&
>=20
> The debute focus later turns to which is best way to use one
> sequential process or two combinarotial process and sequential
> process.
>=20
> The most important and strange thing is that I cannot even find the
> word "combinarotial" in VHDL-2002 specification.
>=20
> I want to grammarly define a combinatorial process which cannot have a
> clock statement in one of my thinking.
>=20
> process_statement_part ::=3D
> { sequential_statement }
>=20
> sequential_statement ::=3D
> wait_statement
> | assertion_statement
> | report_statement
> | signal_assignment_statement
> | variable_assignment_statement
> | procedure_call_statement
> | if_statement
> | case_statement
> | loop_statement
> | next_statement
> | exit_statement
> | return_statement
> | null_statement
>=20
> combinatorial_process_statement_part ::=3D
> { combinatorial_sequential_statement }
>=20
> combinatorial_sequential_statement ::=3D
> assertion_statement	-- wait_statement is deleted here !!!
> | report_statement
> | signal_assignment_statement
> | variable_assignment_statement
> | procedure_call_statement
> | if_statement
> | case_statement
> | loop_statement
> | next_statement
> | exit_statement
> | return_statement
> | null_statement
>=20
> Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstand=
ing of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements i=
nside a block are evaluated one after another. This has no connection whats=
oever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't nee=
d to be specified anywhere in the standard. But when you look into part 4(?=
) of the Standard (The synthesis part) there you find the term "synchronous=
 description". Such a "synchronous description" results in some circuit wit=
h registers. everything else is just gates, and with feedbacks or incomplet=
e conditional branches sometimes to latches, which are identified by the to=
ols, so the designer can decide wether they are intended or not.


Therfore there is no need to make up fancy words and lenghty descriptions f=
or things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed sy=
ntax description:
 combinatorial_process_statement_part ::=3D
{ combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of=20
 =20
  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:
 =20
  wait for 1 ns;

but no event related stuff?=20

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specific=
ation is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Article: 153910
Subject: Re: Replacement for XC4005E
From: MK <mk@nospam.co.uk>
Date: Fri, 29 Jun 2012 08:20:04 +0100
Links: << >>  << T >>  << A >>
On 28/06/2012 17:23, Terry Brown wrote:
> We've been using the venerable XC4005E FPGA from Xilinx for many years
> now in a bunch of products.  However the variant we use has now been
> discontinued, and although we can get sufficient quantities to satisfy
> our quite low (<100 per year) demand it's time to change some of the
> stuff out and redesign where appropriate.  Sadly that'll also mean
> upgrading our toolchain too, but needs must.
>
> Can anyone suggest something similar, not necessarily from Xilinx?  We
> don't do anything much with them, just interface to PC104 (ISA) bus and
> present a bunch of registers in IO space, or stick some custom low-speed
> logic in them, or do address decoding for external chips.
>
> The biggest draw for the 4005 was the 144pin quad flat package which was
> easy on our hand assembly process and the user IO count of 110-ish pins
> which we need to keep or maybe exceed a bit.  Internal logic was always
> drawn as circuits using ViewDraw, don't need any fancy HDL stuff here
> (and in fact could do without the learning curve anyway).  Oh, and also
> 5V IO would be neat (ISA bus interface) but 3.3V logic also would be
> good, because it's getting hard to find a bunch of things in 5V these days.
>
> Any suggestions?
>
> TIA
> Terry
If you are going to jump, a decade into the present you should look at 
some modern parts which you can expect to go on using for while. 
Lattices MachX02 range might do - up to 115 IO in 144 pin package (but 
that is the most expensive part - 108 IO is much cheaper).
If you are paying for the parts you might as well get the best out of 
them - learn an HDL. (Lattice's toolset is pretty cheap and comes with a 
basic version of Aldec HDL which includes a schematic design package 
which I find works best used in combination with VHDl or Verilog).

Michael Kellett


Article: 153911
Subject: Re: Modelsim MXE on wine?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 29 Jun 2012 12:38:59 GMT
Links: << >>  << T >>  << A >>
On Thu, 28 Jun 2012 14:45:54 +0100, nospam wrote:

> I had MXE (Modelsim Xilinx Edition) running successfully under Wine
> until recently. However, following a lot of changes, I 've just
> re-installed it, and can't get vsim running. My setup is SL(/RHEL)6,
> 64-bit, wine 1.2.3. I've installed MXE-III Starter, for both VHDL and
> Verilog. When I run vsim I get a pop-up with a long message which
> starts:
> 
> 'can't read "view_master": no such variable when executing "GUIMAIN"...'
> 
> The problem is in the tcl start-up (tcl/vsim/vsim). Anyone else seen
> this? Any ideas?

I've seen that same error message with Modelsim under Wine.  It was a 
year or two ago using 64 bit Ubuntu so I can't remember the exact details 
but the problem eventually went away when Canonical included a more 
recent version of Wine.

The errors went away with Wine 1.4, however I now use Windows 7 on my 
work computer and versions of Modelsim post 6.something work fine on that.

Regards,
Allan
(followups not set)

Article: 153912
Subject: Re: Replacement for XC4005E
From: Terry Brown <terry@invalid.invalid>
Date: Fri, 29 Jun 2012 13:48:18 +0100
Links: << >>  << T >>  << A >>
On 28/06/2012 17:23, Terry Brown wrote:
>
> Can anyone suggest something similar, not necessarily from Xilinx?...

Thanks to all who replied.  I'm going to look further into he two Xilinx 
CPLDs Jon suggested and the Lattice MachX02 from Michael.  The latter is 
interesting because it has QFP variants which would be good for now but 
also BGA in the same range, and the time is approaching when we are 
going to have to think about transitioning to BGA.  The Xilinx ones are 
probably more useful but may be overkill for current requirements.  The 
Atmel devices JG suggested are probably a little too small for what we need.

We are small volume, and use ~100 FPGAs a year on hand-assembled boards. 
  Cost isn't really an issue, board costs are mostly design, assembly 
and test anyway, a few $ here or there makes no odds.  The biggest 
limitation to date is not being able to do BGA, but we're starting to 
investigate that now as well, but might have difficulty justifying the 
startup cost.  However, anything we do do we'd like to continue to do 
for the next decade, because although we're low volume we get a lot of 
repeats for the same kit over the years, and our customers don't like 
changes.

Looks like I'll still have an issue interfacing to the 5V ISA bus on 
PC104 stacks though, although the Xilinx devices have some 5V tolerant 
inputs, and I guess I can translate the outputs, there aren't that many 
apart from the data bus.

Ah decisions, decisions, decisions ...

Thanks for the input,
Terry


Article: 153913
Subject: Re: Replacement for XC4005E
From: Herbert Kleebauer <klee@unibwm.de>
Date: Fri, 29 Jun 2012 15:38:51 +0200
Links: << >>  << T >>  << A >>
On 29.06.2012 14:48, Terry Brown wrote:

> We are small volume, and use ~100 FPGAs a year on hand-assembled boards. 
>   Cost isn't really an issue, board costs are mostly design, assembly 
> and test anyway, a few $ here or there makes no odds.  The biggest 
> limitation to date is not being able to do BGA, but we're starting to 

Maybe you should take a look at FPGA modules like

http://enterpoint.co.uk/products/pga-modules/darnaw-1/
http://www.hdl.co.jp/en/index.php/plcc68-series.html




Article: 153914
Subject: Re: Replacement for XC4005E
From: Terry Brown <terry@invalid.invalid>
Date: Fri, 29 Jun 2012 15:23:32 +0100
Links: << >>  << T >>  << A >>
On 29/06/2012 14:38, Herbert Kleebauer wrote:
> On 29.06.2012 14:48, Terry Brown wrote:
>
>> We are small volume, and use ~100 FPGAs a year on hand-assembled boards.
>>    Cost isn't really an issue, board costs are mostly design, assembly
>> and test anyway, a few $ here or there makes no odds.  The biggest
>> limitation to date is not being able to do BGA, but we're starting to
>
> Maybe you should take a look at FPGA modules like
>
> http://enterpoint.co.uk/products/pga-modules/darnaw-1/
> http://www.hdl.co.jp/en/index.php/plcc68-series.html

D'y'know, that's an idea!

I wouldn't want to go for a commercial product of that type before, 
though.  We've been burned in the past, for example we developed a 
number of boards using the Virtex-4 Mini-module from Avnet, which was 
fine for 4 years of so until they decided to end-of-life it.  If we had 
been using the raw Virtex on our own boards, they are still available 
and probably will be for years, but because we used the Mini-module 
(which has RAM and EEPROM and Ethernet all on a 1"x2" module) we're a 
bit stuffed.

However, it would be a fairly trivial task to design a board a bit like 
the first one above and have a couple of hundred manufactured 
externally, and then use the module on our own bespoke boards.

To be clearer about what we do, we sell maybe 20 or 30 different boards 
with a wide variety of specialist functions.  No more than 20 of any one 
type in a year, and many of them way less than that, and the boards only 
form part of the final products.  The all use the same FPGA (with 
different bespoke programming of course) and a wide variety of external 
hardware (DAC, ADC, digital IO).  Something like the modules above would 
be good.  Automated assembly is really not an option because of the low 
volumes, which we manage with three techs doing the assembly, and 
external assembly wouldn't save any tech salary (because we need all 
three anyway) but would just increase costs.

On the other hand, there's probably a good argument for embracing BGA 
hand assembly anyway in this day and age, it would open up a bunch of 
stuff that's not available in leaded packages, and things are going more 
and more that way anyway.  Anyone have any experience with it?

Terry




Article: 153915
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 Jun 2012 11:25:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
> Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
> > The following topic may be one of the longest debate in vhdl group:
> > http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9a=
cd78a33d1dae/3de3fe8ea3eec9ad?hl=3Den&q=3Dcombinatorial&lnk=3Dol&
> >=20
> > The debute focus later turns to which is best way to use one
> > sequential process or two combinarotial process and sequential
> > process.
> >=20
> > The most important and strange thing is that I cannot even find the
> > word "combinarotial" in VHDL-2002 specification.
> >=20
> > I want to grammarly define a combinatorial process which cannot have a
> > clock statement in one of my thinking.
> >=20
> > process_statement_part ::=3D
> > { sequential_statement }
> >=20
> > sequential_statement ::=3D
> > wait_statement
> > | assertion_statement
> > | report_statement
> > | signal_assignment_statement
> > | variable_assignment_statement
> > | procedure_call_statement
> > | if_statement
> > | case_statement
> > | loop_statement
> > | next_statement
> > | exit_statement
> > | return_statement
> > | null_statement
> >=20
> > combinatorial_process_statement_part ::=3D
> > { combinatorial_sequential_statement }
> >=20
> > combinatorial_sequential_statement ::=3D
> > assertion_statement	-- wait_statement is deleted here !!!
> > | report_statement
> > | signal_assignment_statement
> > | variable_assignment_statement
> > | procedure_call_statement
> > | if_statement
> > | case_statement
> > | loop_statement
> > | next_statement
> > | exit_statement
> > | return_statement
> > | null_statement
> >=20
> > Weng
>=20
> Hi Weng,
> I think the discussion you mentioned above is caused by a big misundersta=
nding of what the word "sequential" is refering to.
>=20
> "sequential" with respect to the VHDL language means, that the statements=
 inside a block are evaluated one after another. This has no connection wha=
tsoever to the resulting circuit.
>=20
> The opposite of "sequential" here is "concurrent", not "combinatorical".
> "Combinatorical" has no meaning for the language, and therefore doesn't n=
eed to be specified anywhere in the standard. But when you look into part 4=
(?) of the Standard (The synthesis part) there you find the term "synchrono=
us description". Such a "synchronous description" results in some circuit w=
ith registers. everything else is just gates, and with feedbacks or incompl=
ete conditional branches sometimes to latches, which are identified by the =
tools, so the designer can decide wether they are intended or not.
>=20
>=20
> Therfore there is no need to make up fancy words and lenghty descriptions=
 for things that are nicely covered in one compact and generic description.
>=20
> The contradiction of such a request can already be found in the proposed =
syntax description:
>  combinatorial_process_statement_part ::=3D
> { combinatorial_SEQUENTIAL_statement }
>=20
> Does this ease up something?
> and how to avoid the usage of=20
>  =20
>   if rising_edge(clk) then
>=20
> in such a dedicated combinatorical process.
>=20
> and what if in a dedicated non_combinatorical process only this is used:
>  =20
>   wait for 1 ns;
>=20
> but no event related stuff?=20
>=20
> So there's no gain, just increased confusion and waste of paper.
>=20
> A process does what the designer wants it to do.
> Either synchronous or combinatorical. For that purpose one grammar specif=
ication is sufficient.
>=20
> Apply Occams razor.
>=20
> Have a nice synthesis
>   Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that=
 leads to the problem: the concept of a concurrent combinatorial process:=
=20
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit=
, is allowed.
3. In the new process all sequential statements, excluding wait statement, =
are allowed.

Someone may ask that what "a traditional clock statement" means? All those =
who write logic programming in VHDL know it, but there is never a definitio=
n of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, n=
ot by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processe=
s explicitly:
a. always_comb;=20
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.=20

Weng

Article: 153916
Subject: Re: Replacement for XC4005E
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 Jun 2012 12:20:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 29, 8:48 am, Terry Brown <te...@invalid.invalid> wrote:
> On 28/06/2012 17:23, Terry Brown wrote:
>
> > Can anyone suggest something similar, not necessarily from Xilinx?...
>
> Thanks to all who replied.  I'm going to look further into he two Xilinx
> CPLDs Jon suggested and the Lattice MachX02 from Michael.  The latter is
> interesting because it has QFP variants which would be good for now but
> also BGA in the same range, and the time is approaching when we are
> going to have to think about transitioning to BGA.  The Xilinx ones are
> probably more useful but may be overkill for current requirements.  The
> Atmel devices JG suggested are probably a little too small for what we need.

Certainly there are lots of options available, but not may with 5 volt
I/O.  Silicon Blue was offering devices that are 5 volt tolerant, but
that is of limited value when doing a PC/104 interface and those parts
have been obsoleted now that they were bought by Lattice.


> We are small volume, and use ~100 FPGAs a year on hand-assembled boards.
>   Cost isn't really an issue, board costs are mostly design, assembly
> and test anyway, a few $ here or there makes no odds.  The biggest
> limitation to date is not being able to do BGA, but we're starting to
> investigate that now as well, but might have difficulty justifying the
> startup cost.  However, anything we do do we'd like to continue to do
> for the next decade, because although we're low volume we get a lot of
> repeats for the same kit over the years, and our customers don't like
> changes.

Not using BGA packages is an issue, but I still prefer to avoid them
because of the requirements they place on the PCB specs.  Many BGAs
are very fine pitch, 0.5 mm or even 0.4 mm.  This means you need VERY
fine vias to break out the BGA pinout as well as additional layers
driving up the cost of the boards.  But then you say your unit costs
are not important so perhaps this is not an issue.

I think BGA are not so hard to hand assemble.  Do you use a stencil
for solder paste?  Without that you may have a problem.  The BGA needs
solder paste which you set the balls on and a heat gun (without too
much air flow) will melt the balls and the paste.  I had a contract
assembly house try this once and I think he used a lot more air flow
than needed and he kept pushing the part off the pads.  He tried using
glue but then some of the balls didn't get a good connection to the
pads.  But then he wasn't using a stencil or solder paste...

If power consumption is important to you, check out the ICE40 line
from Lattice.  They do have a few parts in 100 QFPs and 144 QFPs
ranging in size from 640 to 3520 LUTs or 150% to nearly 900% the size
of the XC4005E.  Their prices are really good too.


> Looks like I'll still have an issue interfacing to the 5V ISA bus on
> PC104 stacks though, although the Xilinx devices have some 5V tolerant
> inputs, and I guess I can translate the outputs, there aren't that many
> apart from the data bus.

I have found switches to be the preferred method of interfacing to 5
volt signals from 3.3 volt FPGAs.  3.3 volt drivers are high enough to
meet the requirement for 5 volt TTL signals and the switch will
prevent the 5 volt signals from damaging the 3.3 volt I/Os.  The delay
is very slight < 1ns.  A part number for a 10 channel device in a
TSSOP package is SN74CBTD3384CPW.  A 20 channel device is
74CBTD16210.  There should be smaller packages if you want to use
BGAs.

One final comment.  I resisted the switch from schematic to HDL back
in the day.  Now I would not touch schematic.  The single biggest
reason to use HDL is the vendor independence.  It makes it so easy to
switch from one line of devices to another.  Learning an HDL is not
really so tough, especially if you don't do software.  When I learned
I kept thinking it was like other software and it isn't.  It describes
hardware so the code works very differently.  If you need help with
that, I think I could be useful to you in getting up the learning
curve.  I've helped others before.

Rick

Article: 153917
Subject: Re: Replacement for XC4005E
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 29 Jun 2012 14:23:59 -0500
Links: << >>  << T >>  << A >>
Terry Brown wrote:

  Automated assembly is really not an option because of the low
> volumes, which we manage with three techs doing the assembly, and
> external assembly wouldn't save any tech salary (because we need all
> three anyway) but would just increase costs.
> 
Well, I'm a TINY manufacturer, just me and occasionally one of my kids
soldering boards, but I have my own pick and place machine.  The reflow
soldering is done in a toaster oven with thermocouple controller.
(But, maybe I'm nuts.)

> On the other hand, there's probably a good argument for embracing BGA
> hand assembly anyway in this day and age, it would open up a bunch of
> stuff that's not available in leaded packages, and things are going more
> and more that way anyway.  Anyone have any experience with it?
Well, the real problem with BGAs is there is no simple way to inspect the
soldering.  With QFPs and such, a stereo zoom microscope for several
hundred $ and a ring light is about all you need.

Jon

Article: 153918
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 Jun 2012 12:35:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 29, 2:25=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
> > Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
> > > The following topic may be one of the longest debate in vhdl group:
> > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd.=
..
>
> > > The debute focus later turns to which is best way to use one
> > > sequential process or two combinarotial process and sequential
> > > process.
>
> > > The most important and strange thing is that I cannot even find the
> > > word "combinarotial" in VHDL-2002 specification.
>
> > > I want to grammarly define a combinatorial process which cannot have =
a
> > > clock statement in one of my thinking.
>
> > > process_statement_part ::=3D
> > > { sequential_statement }
>
> > > sequential_statement ::=3D
> > > wait_statement
> > > | assertion_statement
> > > | report_statement
> > > | signal_assignment_statement
> > > | variable_assignment_statement
> > > | procedure_call_statement
> > > | if_statement
> > > | case_statement
> > > | loop_statement
> > > | next_statement
> > > | exit_statement
> > > | return_statement
> > > | null_statement
>
> > > combinatorial_process_statement_part ::=3D
> > > { combinatorial_sequential_statement }
>
> > > combinatorial_sequential_statement ::=3D
> > > assertion_statement =A0 -- wait_statement is deleted here !!!
> > > | report_statement
> > > | signal_assignment_statement
> > > | variable_assignment_statement
> > > | procedure_call_statement
> > > | if_statement
> > > | case_statement
> > > | loop_statement
> > > | next_statement
> > > | exit_statement
> > > | return_statement
> > > | null_statement
>
> > > Weng
>
> > Hi Weng,
> > I think the discussion you mentioned above is caused by a big misunders=
tanding of what the word "sequential" is refering to.
>
> > "sequential" with respect to the VHDL language means, that the statemen=
ts inside a block are evaluated one after another. This has no connection w=
hatsoever to the resulting circuit.
>
> > The opposite of "sequential" here is "concurrent", not "combinatorical"=
.
> > "Combinatorical" has no meaning for the language, and therefore doesn't=
 need to be specified anywhere in the standard. But when you look into part=
 4(?) of the Standard (The synthesis part) there you find the term "synchro=
nous description". Such a "synchronous description" results in some circuit=
 with registers. everything else is just gates, and with feedbacks or incom=
plete conditional branches sometimes to latches, which are identified by th=
e tools, so the designer can decide wether they are intended or not.
>
> > Therfore there is no need to make up fancy words and lenghty descriptio=
ns for things that are nicely covered in one compact and generic descriptio=
n.
>
> > The contradiction of such a request can already be found in the propose=
d syntax description:
> > =A0combinatorial_process_statement_part ::=3D
> > { combinatorial_SEQUENTIAL_statement }
>
> > Does this ease up something?
> > and how to avoid the usage of
>
> > =A0 if rising_edge(clk) then
>
> > in such a dedicated combinatorical process.
>
> > and what if in a dedicated non_combinatorical process only this is used=
:
>
> > =A0 wait for 1 ns;
>
> > but no event related stuff?
>
> > So there's no gain, just increased confusion and waste of paper.
>
> > A process does what the designer wants it to do.
> > Either synchronous or combinatorical. For that purpose one grammar spec=
ification is sufficient.
>
> > Apply Occams razor.
>
> > Have a nice synthesis
> > =A0 Eilert
>
> Eilert,
> Actually I want to create something new in HDL, a new type of process, th=
at leads to the problem: the concept of a concurrent combinatorial process:
> 1. The new process is a concurrent process as other processes are.
> 2. In the new process, no traditional clock statement, explicit or implic=
it, is allowed.
> 3. In the new process all sequential statements, excluding wait statement=
, are allowed.
>
> Someone may ask that what "a traditional clock statement" means? All thos=
e who write logic programming in VHDL know it, but there is never a definit=
ion of it in VHDL language. I would like to have someone to fill the gap.
>
> Is it clear enough now?
>
> 1. " if rising_edge(clk) then": the situation will be excluded by note 2,=
 not by grammar.
>
> 2. "wait for 1 ns;": wait statement is prohibited in the grammar.
>
> I don't see any conflicts now.
>
> I appreciate the SystemVerilog grammar by declaring three types of proces=
ses explicitly:
> a. always_comb;
> b. always_latch;
> c. always_ff.
>
> No any ambiguity is generated in any situations.
>
> Thank you for your discussion.
>
> Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Article: 153919
Subject: Re: Replacement for XC4005E
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 29 Jun 2012 19:56:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip)
> One final comment.  I resisted the switch from schematic to HDL back
> in the day.  Now I would not touch schematic.  The single biggest
> reason to use HDL is the vendor independence.  It makes it so easy to
> switch from one line of devices to another.  Learning an HDL is not
> really so tough, especially if you don't do software.  When I learned
> I kept thinking it was like other software and it isn't.  It describes
> hardware so the code works very differently.  If you need help with
> that, I think I could be useful to you in getting up the learning
> curve.  I've helped others before.

I agree. For one, I prefer structural verilog and continuous 
assignment, which looks less like software. 

Also, it helps to have learned about digital logic before, or 
not so long after, you start learning software programming
language(s). 

Think in terms of wires and gates, then write them down.

It is sometimes nice to have an HDL to schematic conversion
program so that you can look at the drawn schematics, but, to
me, hard to use schematic entry. (I keep having to move wires
around when they run into each other.)

-- glen

Article: 153920
Subject: Re: Replacement for XC4005E
From: jg <j.m.granville@gmail.com>
Date: Fri, 29 Jun 2012 14:24:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, June 30, 2012 12:48:18 AM UTC+12, Terry Brown wrote:
> Looks like I'll still have an issue interfacing to the 5V ISA bus on 
> PC104 stacks though, although the Xilinx devices have some 5V tolerant 
> inputs, and I guess I can translate the outputs, there aren't that many 
> apart from the data bus.

 You could use two different devices ? 
 The large IO count tends to bump you up the price curve anyway, so either 2 x 100 pin parts, or 100p + 44p.

 Use an 100p/44p Atmel CPLD for the Level shifting/5V IO and a 100p MachXO2 for the engine room stuff that will not fit into a smaller CPLD.

-jg

Article: 153921
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 Jun 2012 15:31:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
> On Jun 29, 2:25=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
> > > Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
> > > > The following topic may be one of the longest debate in vhdl group:
> > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/b=
d...
> >
> > > > The debute focus later turns to which is best way to use one
> > > > sequential process or two combinarotial process and sequential
> > > > process.
> >
> > > > The most important and strange thing is that I cannot even find the
> > > > word "combinarotial" in VHDL-2002 specification.
> >
> > > > I want to grammarly define a combinatorial process which cannot hav=
e a
> > > > clock statement in one of my thinking.
> >
> > > > process_statement_part ::=3D
> > > > { sequential_statement }
> >
> > > > sequential_statement ::=3D
> > > > wait_statement
> > > > | assertion_statement
> > > > | report_statement
> > > > | signal_assignment_statement
> > > > | variable_assignment_statement
> > > > | procedure_call_statement
> > > > | if_statement
> > > > | case_statement
> > > > | loop_statement
> > > > | next_statement
> > > > | exit_statement
> > > > | return_statement
> > > > | null_statement
> >
> > > > combinatorial_process_statement_part ::=3D
> > > > { combinatorial_sequential_statement }
> >
> > > > combinatorial_sequential_statement ::=3D
> > > > assertion_statement =A0 -- wait_statement is deleted here !!!
> > > > | report_statement
> > > > | signal_assignment_statement
> > > > | variable_assignment_statement
> > > > | procedure_call_statement
> > > > | if_statement
> > > > | case_statement
> > > > | loop_statement
> > > > | next_statement
> > > > | exit_statement
> > > > | return_statement
> > > > | null_statement
> >
> > > > Weng
> >
> > > Hi Weng,
> > > I think the discussion you mentioned above is caused by a big misunde=
rstanding of what the word "sequential" is refering to.
> >
> > > "sequential" with respect to the VHDL language means, that the statem=
ents inside a block are evaluated one after another. This has no connection=
 whatsoever to the resulting circuit.
> >
> > > The opposite of "sequential" here is "concurrent", not "combinatorica=
l".
> > > "Combinatorical" has no meaning for the language, and therefore doesn=
't need to be specified anywhere in the standard. But when you look into pa=
rt 4(?) of the Standard (The synthesis part) there you find the term "synch=
ronous description". Such a "synchronous description" results in some circu=
it with registers. everything else is just gates, and with feedbacks or inc=
omplete conditional branches sometimes to latches, which are identified by =
the tools, so the designer can decide wether they are intended or not.
> >
> > > Therfore there is no need to make up fancy words and lenghty descript=
ions for things that are nicely covered in one compact and generic descript=
ion.
> >
> > > The contradiction of such a request can already be found in the propo=
sed syntax description:
> > > =A0combinatorial_process_statement_part ::=3D
> > > { combinatorial_SEQUENTIAL_statement }
> >
> > > Does this ease up something?
> > > and how to avoid the usage of
> >
> > > =A0 if rising_edge(clk) then
> >
> > > in such a dedicated combinatorical process.
> >
> > > and what if in a dedicated non_combinatorical process only this is us=
ed:
> >
> > > =A0 wait for 1 ns;
> >
> > > but no event related stuff?
> >
> > > So there's no gain, just increased confusion and waste of paper.
> >
> > > A process does what the designer wants it to do.
> > > Either synchronous or combinatorical. For that purpose one grammar sp=
ecification is sufficient.
> >
> > > Apply Occams razor.
> >
> > > Have a nice synthesis
> > > =A0 Eilert
> >
> > Eilert,
> > Actually I want to create something new in HDL, a new type of process, =
that leads to the problem: the concept of a concurrent combinatorial proces=
s:
> > 1. The new process is a concurrent process as other processes are.
> > 2. In the new process, no traditional clock statement, explicit or impl=
icit, is allowed.
> > 3. In the new process all sequential statements, excluding wait stateme=
nt, are allowed.
> >
> > Someone may ask that what "a traditional clock statement" means? All th=
ose who write logic programming in VHDL know it, but there is never a defin=
ition of it in VHDL language. I would like to have someone to fill the gap.
> >
> > Is it clear enough now?
> >
> > 1. " if rising_edge(clk) then": the situation will be excluded by note =
2, not by grammar.
> >
> > 2. "wait for 1 ns;": wait statement is prohibited in the grammar.
> >
> > I don't see any conflicts now.
> >
> > I appreciate the SystemVerilog grammar by declaring three types of proc=
esses explicitly:
> > a. always_comb;
> > b. always_latch;
> > c. always_ff.
> >
> > No any ambiguity is generated in any situations.
> >
> > Thank you for your discussion.
> >
> > Weng
>=20
> I don't see the need for such a new construct.  If you want a
> combinatorial circuit then write the process with all the inputs in
> the sensitivity list, use no feedback of any kind and make sure the
> outputs are defined for all combinations of inputs.  If you want a
> sequential circuit add the reset (if used) and the clock to the
> sensitivity list, use all the feedback you want or don't want and
> don't worry about which combinations of inputs you specify or not.
>=20
> Your "new process" type defined above is not guaranteed to generate
> combinatorial logic because you don't exclude feedback or require all
> input combinations to be defined.  Many a new HDL designer has
> inadvertently left out some input combinations or used feedback and
> ended up with latches.  Heck, even experienced designers do this once
> in a while.
>=20
> The resulting logic comes from how you describe the process, not what
> label you attach.
>=20
> Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate=20
combinatorial logic because you don't exclude feedback or require all=20
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process,=
 how do you generate a ff? latch is allowed to be generated in my case.

Weng

Article: 153922
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Fri, 29 Jun 2012 16:17:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jun 29, 6:31=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
> > On Jun 29, 2:25=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > > On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
> > > > Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
> > > > > The following topic may be one of the longest debate in vhdl grou=
p:
> > > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread=
/bd...
>
> > > > > The debute focus later turns to which is best way to use one
> > > > > sequential process or two combinarotial process and sequential
> > > > > process.
>
> > > > > The most important and strange thing is that I cannot even find t=
he
> > > > > word "combinarotial" in VHDL-2002 specification.
>
> > > > > I want to grammarly define a combinatorial process which cannot h=
ave a
> > > > > clock statement in one of my thinking.
>
> > > > > process_statement_part ::=3D
> > > > > { sequential_statement }
>
> > > > > sequential_statement ::=3D
> > > > > wait_statement
> > > > > | assertion_statement
> > > > > | report_statement
> > > > > | signal_assignment_statement
> > > > > | variable_assignment_statement
> > > > > | procedure_call_statement
> > > > > | if_statement
> > > > > | case_statement
> > > > > | loop_statement
> > > > > | next_statement
> > > > > | exit_statement
> > > > > | return_statement
> > > > > | null_statement
>
> > > > > combinatorial_process_statement_part ::=3D
> > > > > { combinatorial_sequential_statement }
>
> > > > > combinatorial_sequential_statement ::=3D
> > > > > assertion_statement =A0 -- wait_statement is deleted here !!!
> > > > > | report_statement
> > > > > | signal_assignment_statement
> > > > > | variable_assignment_statement
> > > > > | procedure_call_statement
> > > > > | if_statement
> > > > > | case_statement
> > > > > | loop_statement
> > > > > | next_statement
> > > > > | exit_statement
> > > > > | return_statement
> > > > > | null_statement
>
> > > > > Weng
>
> > > > Hi Weng,
> > > > I think the discussion you mentioned above is caused by a big misun=
derstanding of what the word "sequential" is refering to.
>
> > > > "sequential" with respect to the VHDL language means, that the stat=
ements inside a block are evaluated one after another. This has no connecti=
on whatsoever to the resulting circuit.
>
> > > > The opposite of "sequential" here is "concurrent", not "combinatori=
cal".
> > > > "Combinatorical" has no meaning for the language, and therefore doe=
sn't need to be specified anywhere in the standard. But when you look into =
part 4(?) of the Standard (The synthesis part) there you find the term "syn=
chronous description". Such a "synchronous description" results in some cir=
cuit with registers. everything else is just gates, and with feedbacks or i=
ncomplete conditional branches sometimes to latches, which are identified b=
y the tools, so the designer can decide wether they are intended or not.
>
> > > > Therfore there is no need to make up fancy words and lenghty descri=
ptions for things that are nicely covered in one compact and generic descri=
ption.
>
> > > > The contradiction of such a request can already be found in the pro=
posed syntax description:
> > > > =A0combinatorial_process_statement_part ::=3D
> > > > { combinatorial_SEQUENTIAL_statement }
>
> > > > Does this ease up something?
> > > > and how to avoid the usage of
>
> > > > =A0 if rising_edge(clk) then
>
> > > > in such a dedicated combinatorical process.
>
> > > > and what if in a dedicated non_combinatorical process only this is =
used:
>
> > > > =A0 wait for 1 ns;
>
> > > > but no event related stuff?
>
> > > > So there's no gain, just increased confusion and waste of paper.
>
> > > > A process does what the designer wants it to do.
> > > > Either synchronous or combinatorical. For that purpose one grammar =
specification is sufficient.
>
> > > > Apply Occams razor.
>
> > > > Have a nice synthesis
> > > > =A0 Eilert
>
> > > Eilert,
> > > Actually I want to create something new in HDL, a new type of process=
, that leads to the problem: the concept of a concurrent combinatorial proc=
ess:
> > > 1. The new process is a concurrent process as other processes are.
> > > 2. In the new process, no traditional clock statement, explicit or im=
plicit, is allowed.
> > > 3. In the new process all sequential statements, excluding wait state=
ment, are allowed.
>
> > > Someone may ask that what "a traditional clock statement" means? All =
those who write logic programming in VHDL know it, but there is never a def=
inition of it in VHDL language. I would like to have someone to fill the ga=
p.
>
> > > Is it clear enough now?
>
> > > 1. " if rising_edge(clk) then": the situation will be excluded by not=
e 2, not by grammar.
>
> > > 2. "wait for 1 ns;": wait statement is prohibited in the grammar.
>
> > > I don't see any conflicts now.
>
> > > I appreciate the SystemVerilog grammar by declaring three types of pr=
ocesses explicitly:
> > > a. always_comb;
> > > b. always_latch;
> > > c. always_ff.
>
> > > No any ambiguity is generated in any situations.
>
> > > Thank you for your discussion.
>
> > > Weng
>
> > I don't see the need for such a new construct. =A0If you want a
> > combinatorial circuit then write the process with all the inputs in
> > the sensitivity list, use no feedback of any kind and make sure the
> > outputs are defined for all combinations of inputs. =A0If you want a
> > sequential circuit add the reset (if used) and the clock to the
> > sensitivity list, use all the feedback you want or don't want and
> > don't worry about which combinations of inputs you specify or not.
>
> > Your "new process" type defined above is not guaranteed to generate
> > combinatorial logic because you don't exclude feedback or require all
> > input combinations to be defined. =A0Many a new HDL designer has
> > inadvertently left out some input combinations or used feedback and
> > ended up with latches. =A0Heck, even experienced designers do this once
> > in a while.
>
> > The resulting logic comes from how you describe the process, not what
> > label you attach.
>
> > Rick
>
> Rick,
> Your following comment hit the point:
> " Your "new process" type defined above is not guaranteed to generate
> combinatorial logic because you don't exclude feedback or require all
> input combinations to be defined."
>
> If there is no clock statement and not wait statement allowed in a proces=
s, how do you generate a ff? latch is allowed to be generated in my case.
>
> Weng

A latch is a sequential device.  It has memory and that is how
"sequential" is defined.

As I said, I don't see the value of your proposition.  What are you
trying to accomplish?

Rick

Article: 153923
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 Jun 2012 17:09:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:
> On Jun 29, 6:31=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
> > > On Jun 29, 2:25=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > > > On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
> > > > > Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxian=
g:
> > > > > > The following topic may be one of the longest debate in vhdl gr=
oup:
> > > > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/thre=
ad/bd...
> >
> > > > > > The debute focus later turns to which is best way to use one
> > > > > > sequential process or two combinarotial process and sequential
> > > > > > process.
> >
> > > > > > The most important and strange thing is that I cannot even find=
 the
> > > > > > word "combinarotial" in VHDL-2002 specification.
> >
> > > > > > I want to grammarly define a combinatorial process which cannot=
 have a
> > > > > > clock statement in one of my thinking.
> >
> > > > > > process_statement_part ::=3D
> > > > > > { sequential_statement }
> >
> > > > > > sequential_statement ::=3D
> > > > > > wait_statement
> > > > > > | assertion_statement
> > > > > > | report_statement
> > > > > > | signal_assignment_statement
> > > > > > | variable_assignment_statement
> > > > > > | procedure_call_statement
> > > > > > | if_statement
> > > > > > | case_statement
> > > > > > | loop_statement
> > > > > > | next_statement
> > > > > > | exit_statement
> > > > > > | return_statement
> > > > > > | null_statement
> >
> > > > > > combinatorial_process_statement_part ::=3D
> > > > > > { combinatorial_sequential_statement }
> >
> > > > > > combinatorial_sequential_statement ::=3D
> > > > > > assertion_statement =A0 -- wait_statement is deleted here !!!
> > > > > > | report_statement
> > > > > > | signal_assignment_statement
> > > > > > | variable_assignment_statement
> > > > > > | procedure_call_statement
> > > > > > | if_statement
> > > > > > | case_statement
> > > > > > | loop_statement
> > > > > > | next_statement
> > > > > > | exit_statement
> > > > > > | return_statement
> > > > > > | null_statement
> >
> > > > > > Weng
> >
> > > > > Hi Weng,
> > > > > I think the discussion you mentioned above is caused by a big mis=
understanding of what the word "sequential" is refering to.
> >
> > > > > "sequential" with respect to the VHDL language means, that the st=
atements inside a block are evaluated one after another. This has no connec=
tion whatsoever to the resulting circuit.
> >
> > > > > The opposite of "sequential" here is "concurrent", not "combinato=
rical".
> > > > > "Combinatorical" has no meaning for the language, and therefore d=
oesn't need to be specified anywhere in the standard. But when you look int=
o part 4(?) of the Standard (The synthesis part) there you find the term "s=
ynchronous description". Such a "synchronous description" results in some c=
ircuit with registers. everything else is just gates, and with feedbacks or=
 incomplete conditional branches sometimes to latches, which are identified=
 by the tools, so the designer can decide wether they are intended or not.
> >
> > > > > Therfore there is no need to make up fancy words and lenghty desc=
riptions for things that are nicely covered in one compact and generic desc=
ription.
> >
> > > > > The contradiction of such a request can already be found in the p=
roposed syntax description:
> > > > > =A0combinatorial_process_statement_part ::=3D
> > > > > { combinatorial_SEQUENTIAL_statement }
> >
> > > > > Does this ease up something?
> > > > > and how to avoid the usage of
> >
> > > > > =A0 if rising_edge(clk) then
> >
> > > > > in such a dedicated combinatorical process.
> >
> > > > > and what if in a dedicated non_combinatorical process only this i=
s used:
> >
> > > > > =A0 wait for 1 ns;
> >
> > > > > but no event related stuff?
> >
> > > > > So there's no gain, just increased confusion and waste of paper.
> >
> > > > > A process does what the designer wants it to do.
> > > > > Either synchronous or combinatorical. For that purpose one gramma=
r specification is sufficient.
> >
> > > > > Apply Occams razor.
> >
> > > > > Have a nice synthesis
> > > > > =A0 Eilert
> >
> > > > Eilert,
> > > > Actually I want to create something new in HDL, a new type of proce=
ss, that leads to the problem: the concept of a concurrent combinatorial pr=
ocess:
> > > > 1. The new process is a concurrent process as other processes are.
> > > > 2. In the new process, no traditional clock statement, explicit or =
implicit, is allowed.
> > > > 3. In the new process all sequential statements, excluding wait sta=
tement, are allowed.
> >
> > > > Someone may ask that what "a traditional clock statement" means? Al=
l those who write logic programming in VHDL know it, but there is never a d=
efinition of it in VHDL language. I would like to have someone to fill the =
gap.
> >
> > > > Is it clear enough now?
> >
> > > > 1. " if rising_edge(clk) then": the situation will be excluded by n=
ote 2, not by grammar.
> >
> > > > 2. "wait for 1 ns;": wait statement is prohibited in the grammar.
> >
> > > > I don't see any conflicts now.
> >
> > > > I appreciate the SystemVerilog grammar by declaring three types of =
processes explicitly:
> > > > a. always_comb;
> > > > b. always_latch;
> > > > c. always_ff.
> >
> > > > No any ambiguity is generated in any situations.
> >
> > > > Thank you for your discussion.
> >
> > > > Weng
> >
> > > I don't see the need for such a new construct. =A0If you want a
> > > combinatorial circuit then write the process with all the inputs in
> > > the sensitivity list, use no feedback of any kind and make sure the
> > > outputs are defined for all combinations of inputs. =A0If you want a
> > > sequential circuit add the reset (if used) and the clock to the
> > > sensitivity list, use all the feedback you want or don't want and
> > > don't worry about which combinations of inputs you specify or not.
> >
> > > Your "new process" type defined above is not guaranteed to generate
> > > combinatorial logic because you don't exclude feedback or require all
> > > input combinations to be defined. =A0Many a new HDL designer has
> > > inadvertently left out some input combinations or used feedback and
> > > ended up with latches. =A0Heck, even experienced designers do this on=
ce
> > > in a while.
> >
> > > The resulting logic comes from how you describe the process, not what
> > > label you attach.
> >
> > > Rick
> >
> > Rick,
> > Your following comment hit the point:
> > " Your "new process" type defined above is not guaranteed to generate
> > combinatorial logic because you don't exclude feedback or require all
> > input combinations to be defined."
> >
> > If there is no clock statement and not wait statement allowed in a proc=
ess, how do you generate a ff? latch is allowed to be generated in my case.
> >
> > Weng
>=20
> A latch is a sequential device.  It has memory and that is how
> "sequential" is defined.
>=20
> As I said, I don't see the value of your proposition.  What are you
> trying to accomplish?
>=20
> Rick

Hi Rick,
I hope to publish my paper as soon as possible, but I cannot disclose its d=
etails now.

I would like to ask you the question you mentioned earlier and hope you giv=
e me an exception:
If there is no clock statement and not wait statement allowed in a process,=
 how do you generate a ff?=20

latch is allowed to be generated in my case.

After my paper publication, you may have another real opportunity to commen=
t on IF it is useful.

Weng

Article: 153924
Subject: Re: Replacement for XC4005E
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 30 Jun 2012 00:24:01 GMT
Links: << >>  << T >>  << A >>
Jon Elson <jmelson@wustl.edu> wrote:

>Terry Brown wrote:
>
>  Automated assembly is really not an option because of the low
>> volumes, which we manage with three techs doing the assembly, and
>> external assembly wouldn't save any tech salary (because we need all
>> three anyway) but would just increase costs.
>> 
>
>> On the other hand, there's probably a good argument for embracing BGA
>> hand assembly anyway in this day and age, it would open up a bunch of
>> stuff that's not available in leaded packages, and things are going more
>> and more that way anyway.  Anyone have any experience with it?
>Well, the real problem with BGAs is there is no simple way to inspect the
>soldering.  With QFPs and such, a stereo zoom microscope for several
>hundred $ and a ring light is about all you need.

OTOH BGA usually solder well. I have good results with reworking BGAs
using a standard heat gun aka paint stripper.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search