Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 TerryArticle: 153901
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
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: 153903Terry 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. JonArticle: 153904
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. -- glenArticle: 153905
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
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. -jgArticle: 153907
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 FitchArticle: 153908
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. -- glenArticle: 153909
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: 153910On 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 KellettArticle: 153911
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
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, TerryArticle: 153913
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.htmlArticle: 153914
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? TerryArticle: 153915
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: 153916On 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. RickArticle: 153917
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. JonArticle: 153918
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: 153919rickman <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.) -- glenArticle: 153920
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. -jgArticle: 153921
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
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
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: 153924Jon 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:
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