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
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message
news:1188844272.492602.110170@k79g2000hse.googlegroups.com...
<snip>
> The better method to distinguish orif from elsif and that will
> ultimately fend off any future tough questions about it is to put the
> two keywords in two keyword listing tables in text editor's file and
> they will be shown in two different colors, one RED, another PINK, as
> TextPad, Emac, or any text editors do without conventional indent
> practise change. It is a trivial thing, but exaggerated to a
> disadvantage and failure at a strategic level.
Wow....now you're suggesting color coding as a method to handle your
ambiguities?
<snip>
> process (reset, clk) is
> begin
> if reset = '1' then
> outbus <= (others => '0');
> elsif rising_edge(clk) then
> for i in e'range loop
> if e(i) = '1' then
> outbus <= data(i);
> exit;
> end if;
> end loop;
> assert zero_one_hot(e); <-- useless and just waisting time !!!
> end if;
> end process;
>
>
> With your above coding, it seems to me that you don't have a deep
> insight why VHDL needs a mechanism to transfer mutually exclusive
> information to VHDL compiler, neither does Jim.
You haven't demonstrated your insight either...but that's my opinion.
>
> With your coding, it doesn't need to provide the information the
> assertion provides. It is a well known popular practise before
> introducing mutually exclusiveness.
I agree..almost. Sometimes you'll put in these assertions to check the code
you just wrote not so much as a check on what you've just written but as a
check down the road when the code gets modified for whatever reason and the
modifier is maybe unaware of why their change will cause a problem down the
road. A well crafted 'report' after the 'assert' will explain why it is
important and more importantly it will be in 'live code' that actually gets
checked, not in a comment where it is not.
In any case, the assert that was added can be considered a simulation time
waster or info from a maintability standpoint.
Andy's code does not assume mutual exclusiveness it is a priority encoding
to produce outbus.
>
> VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
> 'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
> WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
> when writing software).
That's your 2 cents about what you think compilers need. Do you have ANY
references or evidence to back up that claim? If not, stop shouting it.
>
> We provide EXTRA mutually exclusive information to VHDL compiler and
> let the compiler do better job with the "if...end if" statement
> structure than what you and we have traditionally done. Because
> "if...end if" statements are the simplest and unified way to express
> logic ideas. Any advantages current hardware writing style (shown as
> in your code) would dissapear and become unnecessary if mutually
> exclusive information is given.
Personally I prefer enumerated types to express mutual exclusiveness where
appropriate and sum of products formation (as shown in Jim's example that
you've posted below a bit) where there are things that 'should' be mutually
exclusive but can not be formally shown to be. There are other constructs
besides the 'if' statement that are quite understandable; your assertion
that 'if...endif' is the 'simplest and unified way' represents your opinion
not some grand truth. The fact that you think that it needs to be augmented
with a new 'orif' keyword suggests that the 'if' statement is not quite so
unified after all.
>
> Why the above statement is waistful? You have already written the code
> with the knowledge how it behaves and adding the assertion statement
> just let simulator waisting time to do what you and I never do it
> before. No assertion statement in your code works well and nobody adds
> the assertion statements to confirm it now.
I agree, but as mentioned before, the assert statement with a descriptive
report allows for passing of obscure design information from one design time
to another...sort of a 'heads up' for the designer picking up the code 1
year down the road.
>
> 3. My opinion is when VHDL compilers get more information about
> mutually
> exclusive information, what you can do, the VHDL compilers can do
> better.
And they generally do. Looking at the technology map view of synthesized
code is generally enlightening. In any case, your opinioin has not yet been
substantiated in fact with anything you've posted so far.
>
> VHDL compilers can generate all coding you showed for one level of
> mutually exclusiveness. You may not write efficiently for code with
> two levels or even three levels of mutually exclusiveness. Personal
> power is limited and VHDL compilers can be trained to do more
> mechanical things better than any human.
>
What do you mean my 'two levels' or 'three levels' of mutual exclusiveness?
>
> -- It is Jim's coding
> OutBusA : process(RESET, CLK)
> begin
> if(RESET = '1') then
> OutBus <= (others=>'0');
> elsif rising_edge(CLK) then
> if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
> OutBus <=
> (E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
> (E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
> end if ;
> end if ;
> end process;
>
>
> -- It is my coding
> A : process(RESET, CLK)
> begin
> if(RESET = '1') then
> OutBus <= (others=>'0');
> elsif rising_edge(CLK) then
> if(E0 = '1') then
> OutBus <= Data0;
> orif(E1 = '1') then
> OutBus <= Data1;
> orif(E2 = '1') then
> OutBus <= Data2;
> orif(E3 = '1') then
> OutBus <= Data3;
> orif(E4 = '1') then
> OutBus <= Data4;
> orif(E5 = '1') then
> OutBus <= Data5;
> else
> OutBus <= OutBus;
> end if;
> end if;
> end process;
>
>
> The above equation would be implemented in Xilinx chip with carry
> chain with initial input data to the carry chain being OutBus. The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'
>
I don't think so, unless you assume the various 'E' are one hot encoded.
Had Jim made that assumption he would have written it without the "if (E0 or
E1 or E2 or E3 or E4 or E5) = '1'" as well I'm sure. In any case, as
written, Jim's handles the case where none of the 'E' happen to be set.
Whether or not this is appropriate depends on what assumptions there are
with 'E'; personally I would think that the condition where none is set is
probably the more common case when bringing together various external
signals and trying to say that they are in some sense mutually exclusive.
>
> It is not a LUT or two saving as some suggesed. For a up to 400MHz
> project, every extra logic would kill a design. Because it takes more
> route resources. When route resources exhausted, the running
> frequency would drop dramatically and would kill a otherwise successfu
> design.
> LUT is less than a cent in a FPGA.
But you've presented nothing to indicate that 'orif' would map to anything
different. In fact, you can not. The rules of boolean logic require only
'and', 'or' and 'not', they do not require 'orif'. You claim (but present
no evidence) that the new 'orif' keyword could in some cases present some
resource or timing improvement but you have no basis for that claim and
nothing at all to back it up. Looking at source code examples and
suggesting that it would improve anything is naive at best.
The only claim you could possibly make is that 'orif' is a productivity
enhancer perhaps because it is fewer lines of code (but by perusing Andy,
Jim and your code it would seem that 'orif' is the longest) or because it is
less error prone in use (doesn't appear to be).
In case you're interested, Andy's version consumes 9 logic elements and has
four levels of logic; Jim's version consumes 6 logic elements and has three
levels of logic. The difference comes about because Jim's version take full
advantage of the supposed knowledge that the data inputs are all mutually
exclusive whereas Andy's makes no such assumption. These were benchmarked
using Quartus targetting a Cyclone II which has 4 input LUTs as the logic
primitive. Code I used posted at the end of this posting.
>
> 5. orif or other similar spelling OIF, _ORIF, is not replacable with
> assertion function.
Actually that's a good thing about 'orif'. Logic should be described by
logic functions not assertions. Those that are proposing using assertions
to drive the synthesized code in some fashion are barking up a bad
tree....what happens when the supposedly impossible happens and the asserted
condition is no longer met? What will the synthesized result produce? It
better be what is described in the logic description which therefore implies
that the asserted statements really should be ignored during synthesis for
the purposes of optomizing any logic functions.
>
> 6, My another keyword method: Exclusive(or other name, no problem).
>
> Here is an example how Exclusive is used:
>
> signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data
>
> Exclusive : (A); -- it indicates that signal A of its bits is mutually
> exclusive.
What guarantees the exclusiveness? The engineer's code of honor? If it is
reeeeeally mutually exclusive it could be described by an enumerated type.
>
> Exclusive : (StateRead, StateWrite); -- indicate two state machines
> are mutually exclusive with their intial states being common. This
> function extends mutually exclusive funtion to more than 2 state
> machines.
Kind of looks like an enumerated type definition too....hmmm
>
> If you need, I can send my paper to you: "HDL Code Inefficiency
> Sources and Its Solutions".
>
> Jim,
>
> I am going to publish 6 articles in a batch within next 6 months in
> one of three forms: websites, patent applications or international
> conferences. One of them has a very good example how 'orif' is used, a
> brand new usage. No special report to you is under consideration until
> you are pursuaded in advance. You may have to wait for next 6 months
> to get the files.
>
Hopefully you'll present actual results to back up your so far baseless
claims, it would make for a much stronger case for 'orif'. Good luck with
your work.
KJ
Jim and Andy's versions implemented below. Uncomment out the one you'd like
to synthesize with. By the way, Jim, Andy and Weng's code as presented in
this thread are all flawed and not compilable. In some cases, 'outbus' is
treated as a vector, in others it is treated as a single bit. I modified
each so that 'outbus' is a single bit which appears to be the real intent
here....apologies if it's not.
--------- CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ----------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity test is
port (
clk: in std_ulogic;
reset: in std_ulogic;
e: in std_ulogic_vector(7 downto 0);
data: in std_ulogic_vector(7 downto 0);
outbus: out std_ulogic);
end entity test;
architecture rtl of test is
begin
-- Andy's code
-- process (reset, clk) is
-- begin
-- if reset = '1' then
-- outbus <= '0';
-- elsif rising_edge(clk) then
-- for i in e'range loop
-- if e(i) = '1' then
-- outbus <= data(i);
-- exit;
-- end if;
-- end loop;
-- -- assert zero_one_hot(e); -- useless and just waisting time !!!
-- end if;
-- end process;
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= '0';
elsif rising_edge(CLK) then
if (E(0) or E(1) or E(2) or E(3) or E(4) or E(5)) = '1' then
OutBus <=
(E(0) and Data(0)) or (E(1) and Data(1)) or (E(2) and Data(2)) or
(E(3) and Data(3)) or (E(4) and Data(4)) or (E(5) and Data(5)) ;
end if ;
end if ;
end process;
end architecture rtl;
--------- END CODE USED TO IMPLEMENT ANDY AND JIM'S VERSION ----------
Article: 123751On szept. 3, 22:06, benr...@gmail.com wrote: > As I can see you have three interrupt sources but PARAMETER > C_NUM_INTR_INPUTS = 2 > Better delete this line, it will be "Auto Computed". > Then your memory runs at 66MHz (and might pass the tests) but > according to the datasheet you need at least 75MHz to run it properly. > My advice is to try building the system for 50MHz. You'll get the > dcm's configured to run the mem at 100MHz. > Then use the ref design to tune it for 66/133 > BR Thank you for your help! I'll regenerate the design with these options...Article: 123752
Andreas Ehliar wrote: (snip) > Longer disclaimer: > Since I don't work at Xilinx I have no idea how the routing inside > Xilinx devices is actually implemented but it seems like some nets > can be driven from either side depending on how the FPGA is > configured. That might be implemented with some sort of tristate > buffers. (Unless this is just a simplification in the FPGA > editor of how it really works. The xdl report file also hints that > there are some nets that can be driven in both directions.) > Anyway, as a user of the device we don't really have to care about > these details. As I understand it, it is related to the physics of the device. As the wires get narrower and longer, the resistance increases faster than the capacitance decreases. The solution is to put buffers along the line. As the buffers need a direction, that makes it hard to do true tri-state that the earlier Xilinx devices did. The solution is to use a mux, possibly driven by a priority encoder, maybe just using AND or OR onto the output line. It should work such that it gives the right result when only one is selected. -- glenArticle: 123753
On Aug 30, 6:55 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > If I am designing a pcb using impedance controlled layers can I treat the > power planes as a reference layer as well as the gnd layers? > > Cheers > > Jon The way I've heard it done is that you can you a power plane as a reference if it is the actual power used for the driver of your impedance controlled net.Article: 123754
On 3 Sep., 09:53, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Every synth tool I've used issues a warning or error when it ignores > initial values. It's a tool restriction I've learnt to live with. > On FPGAs with well-defined config values, I work around it by > providing an explicit asynchronous reset in the usual way and then > tying-off that reset to "false" somewhere in the top-level wrapper > that organises the design for the target platform. That gives me > no additional hardware cost in the FPGAs that I've used, and it > gives me a different, clumsier, but equally effective way to > specify initial values. No it is not. There are two bad things that can happen: 1. Constant propagation is a simple task for logic synthesis. The reset might be removed from the DFFs bacause it is not needed. There is no requirement for the tool to infer the power on value from the async reset value. In fact, doing so could violate the spec. If I code a dynamic reset of '1' and a power up value of '0' the tool must not set the power up value to '1'. Especially not if it can infer that there never will be a dynamic reset. 2. If constant propagation on reset nets is prohibited by the tool to preserve the reset values in the case you describe your never-used sync reset prevents the use of the sync reset for logic optimization. The resulting logic might be more than 50% larger than necessary. It is more a dirty hack to trick the tools in the desired behaviour than it is an effective way to specify initial values. Any tool is free to break your implentation and will still be in compliance with the language spec. Kolja SulimmaArticle: 123755
Hi, Internal tristates are gone from Xilinx devices. There is a way of implement efficient large muxes by using DFFs and the carry-chain. The solution is using many DFFs but usually you use less DFFs than LUTs in a design. You would let each source to mux passing through a DFF with a synchronous reset. All DFFs are kept in reset state except the source that you have selected to mux. This allows you to just OR all the sources since only the selected sources is not under reset. The ORing can be done using carry-chain to even further decrease the LUT usage. It's it in fact an AND-OR structure but the AND is coming from the synchronous reset in a DFF Example. 16-bit busses and you need a 16-1 mux. Using normal muxes would require 16*8 = 128 LUTs With this solution you would need 4 LUTs for ORing 16 sources. So the 16-1 mux would consume 16*4 = 64 LUTs and 16*16 = 256 DFFs. So the DFFs usages is high but you have 50% less LUT usage. Göran "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:PJ-dnWy_lOX-dkHbnZ2dnUVZ_oOnnZ2d@comcast.com... > Andreas Ehliar wrote: > (snip) > >> Longer disclaimer: >> Since I don't work at Xilinx I have no idea how the routing inside >> Xilinx devices is actually implemented but it seems like some nets >> can be driven from either side depending on how the FPGA is >> configured. That might be implemented with some sort of tristate >> buffers. (Unless this is just a simplification in the FPGA >> editor of how it really works. The xdl report file also hints that >> there are some nets that can be driven in both directions.) >> Anyway, as a user of the device we don't really have to care about >> these details. > > As I understand it, it is related to the physics of the device. > As the wires get narrower and longer, the resistance increases > faster than the capacitance decreases. The solution is to put > buffers along the line. As the buffers need a direction, that makes > it hard to do true tri-state that the earlier Xilinx devices did. > > The solution is to use a mux, possibly driven by a priority > encoder, maybe just using AND or OR onto the output line. It should > work such that it gives the right result when only one is selected. > > -- glen >Article: 123756
On Tue, 04 Sep 2007 07:16:36 -0000, "comp.arch.fpga" wrote: >On 3 Sep., 09:53, Jonathan Bromley wrote: [an asynch reset, tied false] >> gives me a different, clumsier, but equally effective way to >> specify initial values. > >No it is not. There are two bad things that can happen: Agreed with both your points, although my experience is consistently that those bad things do *not* happen in practice. >It is more a dirty hack to trick the tools in the desired behaviour >than it is an effective way to specify initial values. >Any tool is free to break your implentation and will still be in >compliance with the language spec. Guilty as charged. There's no doubt that synthesis support for initialization values - with, of course, checks that it been applied only to variables or signals that represent a flip-flop - would be the best solution by far. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123757
Hi John, I hope you had a relaxing Labor Day? Anyway, against my better judgement, I thought I'd have another go at this thread! Comments below. "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:c5kld3pnm5nv9cen4771p882s0s4d92e2s@4ax.com... > > Except in extreme situations, it's safe to assume that parallel planes > in a multilayer pcb, bypassed with scattered caps, is an equipotential > structure. It's that simple. > > > John > Aha. Now we're getting somewhere. You seem to have shifted position from your previous post when you said about bypass capacitors:- "That's not necessary. There's already so much plane-plane capacitance that the planes are already equipotential as far as the tiny charge injected by the signal trace can affect them." At least you now seem to endorse the need for scattered caps. Progress indeed. ;-) OK, from your other post in reply to Hal:- "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:lvild3ti0v1d62brnaahoulljhpib8p2s5@4ax.com... > > I've experimentally TDR tested plane cuts, and they are generally > invisible as long as they are thin as compared to board thickness, or > if the ground plane slit is shorted out by an adjacent power plane. > > All this popular "return current" theorizing is madness. There's so > much dielectric shorting a small slit that a signal trace cruises over > it and never sees it. > > Spend s few minutes with a hunk of copperclad, some edge-launch SMAs, > an xacto knife, and a 20 GHz TDR scope. It's enlightening. The other > fun thing to do is to add some "classicly bad" trace/slit/via > structures into spare bits of production boards and TDR them. > > John > As you appear to enjoy rubbishing the links I post up here to illustrate my points, and to keep you in practice, here's some more cannon fodder for you! I found a site online with a guy who's taken your advice and got out his scalpel and test equipment. (I hope you don't find this site dangerously moronic. ;-) ) Here http://www.emcesd.com/tt2003/tt020103.htm is an experiment in which the ground plane cut is thin as compared to board thickness. Why don't his results match your invisibility prediction? (I agree that this doesn't show the ground plane shorted by a power plane, but you did say 'or'. I also wonder what is the situation you envisage that would have a ground plane break shorted by another plane?) Next, here http://www.emcesd.com/tt2006/tt050106.htm is an experiment in which a signal passes through a board and switches reference from one plane to another. The results would appear to disagree with your original assertion that vias and bypass caps are "not necessary". (Of course, now a 'scattering' is good!) With tongue firmly in cheek, and with eager anticipation of your reply, Best regards, Syms.Article: 123758
Hello, I would like to know if someone had already used the Wind River Workbench software to debug the PowerPC405 in the FPGA Virtex II Pro ? If yes, how you have imported the Xilinx SDK Project in Wind River Workbench ? You build a specific makefile and imported the Xilinx libraries ? Thanks, Laurent.Article: 123759
Hello, I created an ipcore opb2ip_bridge (with edk's wizard) interfacing the opb and added it to the edk reference design. So far, so good. While running generate bitstream, synthesis stage runs through, but implementation stage aborts immediately with ERROR:NgdBuild:604. --------------------------- logfile excerpt: ERROR:NgdBuild:604 - logical block 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleA_0' with type 'moduleA' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'moduleA' is not supported in target 'virtex2p'. ERROR:NgdBuild:604 - logical block 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleB_0' with type 'moduleB' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'moduleB' is not supported in target 'virtex2p'. --------------------------- My userdefined ipcore is unitized in a hierarchy of vhdl modules like: -opb2ip_bridge |-USER_LOGIC ||-moduleA ||-moduleB |||-moduleA Could this be the reason for the error. If so, is there any configuration file, I would have to modify previously to make the synthesis/ implementation stage be aware that my ipcore is designed modular and how to resolve the symbol names. Or what is the real problem and how do I have to solve it. I'm working under edk and ise version 8 and latest service packs. The reference design is not the problem, because it's already working in other designs. Thanks for you help. Greetings, Lars.Article: 123760
On Sep 4, 7:37 am, "L. Schreiber" <l.s.rock...@web.de> wrote: > Hello, > > I created an ipcore opb2ip_bridge (with edk's wizard) interfacing the > opb and added it to the edk reference design. So far, so good. While > running generate bitstream, synthesis stage runs through, but > implementation stage aborts immediately with ERROR:NgdBuild:604. > > --------------------------- > logfile excerpt: > ERROR:NgdBuild:604 - logical block > 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleA_0' with type > 'moduleA' could not be resolved. A pin name misspelling can cause this, > a missing edif or ngc file, or the misspelling of a type name. Symbol > 'moduleA' is not supported in target 'virtex2p'. > > ERROR:NgdBuild:604 - logical block > 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleB_0' with type > 'moduleB' could not be resolved. A pin name misspelling can cause this, > a missing edif or ngc file, or the misspelling of a type name. Symbol > 'moduleB' is not supported in target 'virtex2p'. > --------------------------- > > My userdefined ipcore is unitized in a hierarchy of vhdl modules like: > > -opb2ip_bridge > |-USER_LOGIC > ||-moduleA > ||-moduleB > |||-moduleA > > Could this be the reason for the error. If so, is there any > configuration file, I would have to modify previously to make the > synthesis/ implementation stage be aware that my ipcore is designed > modular and how to resolve the symbol names. > > Or what is the real problem and how do I have to solve it. > > I'm working under edk and ise version 8 and latest service packs. The > reference design is not the problem, because it's already working in > other designs. > > Thanks for you help. > Greetings, Lars. I've seen something similar with COREgen modules in mixed language designs. Is moduleB a black box? Do you have a .ngc file created for moduleB? Is it in the project directory? If you answer yes to all three questions, then there is the possibility that ISE is looking for your .ngc code in another file such as moduleB_0.ngc due to the hierarchy created. In that case copying moduleB.ngc to moduleB_0.ngc can fix the problem. The same would apply to moduleA. HTH, GaborArticle: 123761
Gabor schrieb: > On Sep 4, 7:37 am, "L. Schreiber" <l.s.rock...@web.de> wrote: >> Hello, >> >> I created an ipcore opb2ip_bridge (with edk's wizard) interfacing the >> opb and added it to the edk reference design. So far, so good. While >> running generate bitstream, synthesis stage runs through, but >> implementation stage aborts immediately with ERROR:NgdBuild:604. >> >> --------------------------- >> logfile excerpt: >> ERROR:NgdBuild:604 - logical block >> 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleA_0' with type >> 'moduleA' could not be resolved. A pin name misspelling can cause this, >> a missing edif or ngc file, or the misspelling of a type name. Symbol >> 'moduleA' is not supported in target 'virtex2p'. >> >> ERROR:NgdBuild:604 - logical block >> 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleB_0' with type >> 'moduleB' could not be resolved. A pin name misspelling can cause this, >> a missing edif or ngc file, or the misspelling of a type name. Symbol >> 'moduleB' is not supported in target 'virtex2p'. >> --------------------------- >> >> My userdefined ipcore is unitized in a hierarchy of vhdl modules like: >> >> -opb2ip_bridge >> |-USER_LOGIC >> ||-moduleA >> ||-moduleB >> |||-moduleA >> >> Could this be the reason for the error. If so, is there any >> configuration file, I would have to modify previously to make the >> synthesis/ implementation stage be aware that my ipcore is designed >> modular and how to resolve the symbol names. >> >> Or what is the real problem and how do I have to solve it. >> >> I'm working under edk and ise version 8 and latest service packs. The >> reference design is not the problem, because it's already working in >> other designs. >> >> Thanks for you help. >> Greetings, Lars. > > > I've seen something similar with COREgen modules in mixed language > designs. No, it's a vhdl only design. > Is moduleB a black box? No, there are no black-box attributed instances inside the peripheral ip design. > Do you have a .ngc file created for moduleB? No, it doesn't seem, that the edk has built ngc files for the submodules of the ip while executing "generate bitstreams" . Inside the implementations directory there is only a opb2ip_0_wrapper.ngc for the toplevel of my ipcore besides all the ngc files from the reference design. > Is it in the project directory? My ip lies inside an external ip repository and is linked into the edk reference design project. > If you answer yes to all three questions, then there is the > possibility > that ISE is looking for your .ngc code in another file such as > moduleB_0.ngc due to the hierarchy created. In that case copying > moduleB.ngc to moduleB_0.ngc can fix the problem. > > The same would apply to moduleA. > > HTH, > GaborArticle: 123762
> > P.S.: Here is another coding style, assuming the inputs and Es are in > arrays: > > output := (others =>'-'); -- this line allows the compiler to do the > optimization, most compilers DECIDE against it > for i in input'range loop > if e = (i=>'1', others=>'0') then output := intput(i); > end loop; > > if you know the optimization and want to force it: > for i in input'range loop > if e(i) = '1' then output := output or intput(i); > end loop; In the (Jim's?) original example, the output was unchanged if no enable bits were set. Therefore the additional check on e1 or e2 or e3... is necessary to make sure that only if any enable bit is set does the output get a new value. An initial assignment to (others => '-') only takes care of the case if no enables are set. The order of execution of the loop provides priority coding, in that the rightmost bit of enable that is set will win (in the first example), no matter how many are set. AndyArticle: 123763
On Aug 31, 9:16 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > 3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002 > today and started reading them. I have no interest to learn PSL. I am > more interested in algorithms and circuit development, not the VHDL > language. For my personal use, VHDL-1993 standard plus 'orif' is > enough. That I am pushing for 'orif' adoption is only for my personal > use. Now I don't need it as desperately as before. So you are not interested in what VHDL already has, you just want to blindly add duplicative, invasive new features to the language so that you don't have to learn these existing, more powerful methods? This is not a language issue. The language already supports communicating mutual exclusivity and many more powerful notions. Existing synthesis tools do not use the information; that is the problem. It would help them if there was "a standard way" to communicate this to them (which is possible within the existing language). Just like there is a standard way to communicate a synchronous process that implies flip flops: there are lots of ways to describe that behavior in VHDL, but only certain ones are universally accepted by synthesis tools. AndyArticle: 123764
On Sep 4, 6:41 am, Andy <jonesa...@comcast.net> wrote: > On Aug 31, 9:16 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > 3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002 > > today and started reading them. I have no interest to learn PSL. I am > > more interested in algorithms and circuit development, not the VHDL > > language. For my personal use, VHDL-1993 standard plus 'orif' is > > enough. That I am pushing for 'orif' adoption is only for my personal > > use. Now I don't need it as desperately as before. > > So you are not interested in what VHDL already has, you just want to > blindly add duplicative, invasive new features to the language so that > you don't have to learn these existing, more powerful methods? > > This is not a language issue. The language already supports > communicating mutual exclusivity and many more powerful notions. > Existing synthesis tools do not use the information; that is the > problem. It would help them if there was "a standard way" to > communicate this to them (which is possible within the existing > language). Just like there is a standard way to communicate a > synchronous process that implies flip flops: there are lots of ways to > describe that behavior in VHDL, but only certain ones are universally > accepted by synthesis tools. > > Andy Hi Andy, I accept your advice and will learn PSL I have ordered one of 3 books Colin suggested, and found that they don't contain PSL. I will print VHDL-2006 today. Are you sure that Jim's assertion method in communicating mutually exclusivity to VHDL compiler is good enough without need for 'orif' introduction? 1. As I described before, if you use Jim's method and want to get the information to compiler, you must insist the 'if...end if' structure to get the benefits, otherwise it is useless, meaningless and wasting time. 2. When you use 'if...end if' structure, 'orif' is the best choice, no question! You can add the information line by line at any levels as you want. 3. My goal is to make writing VHDL for a hardware engineer as easy as writing C for a software engineer using 'if...end if' structure with mixing 'elsif' and 'orif'. Thank you. WengArticle: 123765
On Tue, 4 Sep 2007 11:42:54 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >Hi John, > >I hope you had a relaxing Labor Day? Anyway, against my better judgement, I >thought I'd have another go at this thread! Comments below. > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:c5kld3pnm5nv9cen4771p882s0s4d92e2s@4ax.com... >> >> Except in extreme situations, it's safe to assume that parallel planes >> in a multilayer pcb, bypassed with scattered caps, is an equipotential >> structure. It's that simple. >> >> >> John >> > >Aha. Now we're getting somewhere. You seem to have shifted position from >your previous post when you said about bypass capacitors:- > >"That's not necessary. There's already so much plane-plane capacitance that >the planes are already equipotential as far as the tiny charge injected by >the signal trace can affect them." > >At least you now seem to endorse the need for scattered caps. Progress >indeed. ;-) > >OK, from your other post in reply to Hal:- > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:lvild3ti0v1d62brnaahoulljhpib8p2s5@4ax.com... >> >> I've experimentally TDR tested plane cuts, and they are generally >> invisible as long as they are thin as compared to board thickness, or >> if the ground plane slit is shorted out by an adjacent power plane. >> >> All this popular "return current" theorizing is madness. There's so >> much dielectric shorting a small slit that a signal trace cruises over >> it and never sees it. >> >> Spend s few minutes with a hunk of copperclad, some edge-launch SMAs, >> an xacto knife, and a 20 GHz TDR scope. It's enlightening. The other >> fun thing to do is to add some "classicly bad" trace/slit/via >> structures into spare bits of production boards and TDR them. >> >> John >> > >As you appear to enjoy rubbishing the links I post up here to illustrate my >points, and to keep you in practice, here's some more cannon fodder for you! >I found a site online with a guy who's taken your advice and got out his >scalpel and test equipment. (I hope you don't find this site dangerously >moronic. ;-) ) Out of politeness... no comment. > >Here http://www.emcesd.com/tt2003/tt020103.htm is an experiment in which the >ground plane cut is thin as compared to board thickness. Why don't his >results match your invisibility prediction? (I agree that this doesn't show >the ground plane shorted by a power plane, but you did say 'or'. My results are different from his because we're doing totally different things. I'm TDRing microstrip traces on production multilayer boards, measuring impedances, reflection, and transmission; he's firing spark gaps at, essentially, home-made slot antennas. My measurements are quantified; his aren't. >I also >wonder what is the situation you envisage that would have a ground plane >break shorted by another plane?) "Shorted" in the AC sense, which merely requires a solid plane in a layer adjacent to the slit. > >Next, here http://www.emcesd.com/tt2006/tt050106.htm is an experiment in >which a signal passes through a board and switches reference from one plane >to another. The results would appear to disagree with your original >assertion that vias and bypass caps are "not necessary". (Of course, now a >'scattering' is good!) Bizarre. This guy can't even afford real pc boards, so has to fake it with wire and old copperclad. Fig 3 is hilarious; of course a signal radiates more on the side it's exposed to the antenna. Of course vias are inductive discontinuties. > >With tongue firmly in cheek, and with eager anticipation of your reply, As far as I can tell by TDR measurements, parallel planes in a PC board look like a perfect capacitor. I haven't been able to resolve any edge-echo effects, which would be associated with plane resonances. I assume that's because the parallel planes form a very low impedance transmission-line thing with low Q. If you design an SMA connector into a multilayer pcb, which I occasionally do for amusement, you can TDR the planes. A typical plane will look like a perfect cap to 15 GHz, my limit of measurement. As you solder in bypass caps, the effective C goes up, irrespective of where you add the caps. That's true enough to make my stuff work: http://www.highlandtechnology.com/DSS/P400DS.html http://www.highlandtechnology.com/DSS/V880DS.html http://www.highlandtechnology.com/DSS/V346DS.html http://www.highlandtechnology.com/DSS/T220DS.html Caps are of course necessary to store energy, to handle the slow parts of load transients, since the plane capacitances are low, ballpark 100-200 pF per square inch. So it's easy to lay out boards with close power/ground planes and a scattering of ceramic bypass caps, 0.33 uF maybe, to break up any conjectured plane resonances (which I can't see!), and provide energy storage for the slow stuff. Just put some caps wherever convenient. Look at it this way: if you use power planes and bypass caps to provide a stiff, wideband, low-impedance power supply to your chips, and you do it well, then there will be very little noise on any power pour relative to ground, even when it's whacked by big chip Vcc current spikes. So if the power plane is this equipotential to ground, why would a signal trace, switching "reference layer", notice that it's a different "reference"? The current poked into a plane by a signal zipping past is a minute fraction of the current spikes coming out of the power pin of a processor or an FPGA or even a CMOS gate. JohnArticle: 123766
On Mon, 03 Sep 2007 23:30:16 -0700, kayrock66@yahoo.com wrote: >On Aug 30, 6:55 am, "maxascent" <maxasc...@yahoo.co.uk> wrote: >> Hi >> >> If I am designing a pcb using impedance controlled layers can I treat the >> power planes as a reference layer as well as the gnd layers? >> >> Cheers >> >> Jon > >The way I've heard it done is that you can you a power plane as a >reference if it is the actual power used for the driver of your >impedance controlled net. How does the rising edge of a signal, or even better the falling edge, know what power supply launched it? JohnArticle: 123767
KJ, Thanks for pointing out that my example, without the assertion, assumes priority encoding, and not mutual exclusivity. This is often forgotten in sequential code. The only problem with enumerated types is that they are not applicable to an arbitrary (i.e. parameterizable) number of values. So a uniform way of encoding a arbitrary length vector as enumerated values does not exist. However, one could choose binary encoding of a one hot value as an alternative. The trick is doing binary encoding in a way that takes advantage of mutual exclusivity. It can be done, but I have not experimented to find out if the encode/decode is able to be optimized out. output <= data(to_integer(unsigned(one_hot_encode(e)))); Where one_hot_encode() is a function that optimally (without priority) converts a one_hot slv to a smaller, binary value slv. Additional code is needed to handle the zero_hot case. If one was willing to assume that vector lengths could be limited to 2**31 bits, then one_hot_encode() could return an integer, making its use a little simpler: output <- data(one_hot_encode(e)); The optimal coding of one_hot_encode() is left as an excercise for the user. ;^) BTW, I assumed "data" was an array of std_logic_vector in my example; so my version worked as was with the appropriate declaration. AndyArticle: 123768
I have a design that uses a 100Mhz system clock, but only a very small
portion actually runs at 100MHz. The rest of the FFs in the design
use a synchronous "clk_10M_en" signal which is active for one clock
period and repeats every 100ns. I would like to know how to specify
the constraints correctly so that Actel Designer (i.e. SmartTime))
knows "that paths FROM FFs using clk_10M_en TO FFs using clk_10M_en"
are 100ns paths, not 10ns paths.
It's quiet easy to add a multicycle path constraint on the two
registers, such as:
set_multicycle_path 10 -from {reg1:CLK} -to {reg2:CLK}
But what I need is a solution that can find these registers when they
are buried in a hierarchy of modules. Since they all use clk_10M_en
as their enable, there should be a way to perform a "find" and then
set a multicycle path constraint between each regsiter.
I have contacted Actel but they refer me to their docs or using the
GUI tools which does not solve my problem.
Surely this can be done via the .sdc constraints file using some TCL
code.
TIA.
David
Article: 123769Hi, Apologies if this isn't the best group, but there doesn't appear to be a comp.arch.cpld group. I'm going to start learning about CPLDs to use them in my projects, but the algorithm I've developed will require a few CPLDs working on different parts of the algorithm in sequence. So part A of the algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They are all complete guesses at the moment, as I know next to nothing about PLDs in general, but I know that for my algorithm to run as fast as required, I will require multiple PLDs. I'm choosing CPLDs as from what I've read FPGAs can be a bit overbearing for a beginner due to the amount of features/number of gates they have, also CPLDs have more predictable timing? So, I'm wondering just how difficult using multiple CPLDs on a custom PCB actually is? I'm sure it's achievable, but I would like to know how difficult this could be. Also, could any simulators be used to simulate a complex design with multiple CPLDs on a PCB? Finally, could anybody recommend any books for getting started in the CPLD world - I'm unsure to use Verilog or VHDL at the moment? Thanks for your time. Nick.Article: 123770
On Sep 3, 1:53 am, James Harris <james.harri...@googlemail.com> wrote: > Shooting from the hip somewhat I think I could start with about seven > ports (to test the concept) each being 8-bit. I need to pass a strobe > with each input to the switch and possibly an acknowledge fed /back/ > from each output. So there would be 10 bits (8 data + 1 strobe + 1 > ack) per port leading, I think, to a 70x70 crossbar. Isn't that a 7x7 crossbar with 10 bit data path , 3 bits of addressing to specify a port? total size would be 10*2*7=140 LUTs for crossbar port input mux tree. Much different problem than a 70x70 single bit data path with 7 bits of addressing. That problem requires 70*64=4,480 LUTs.Article: 123771
Is your moduleA and moduleB listed in the PAO file? If is not listed in the PAO, then it will not synthesized by XST. Xst will give a warning that the moduleA and moduleB are black box components. Take a looke at you <proj_directory>/synthesis/opb2ip_bridge_0_xst.srp This is the syntesis report file for your component. Look for warnings regarding moduleA and moduleB. L. Schreiber wrote: > Gabor schrieb: >> On Sep 4, 7:37 am, "L. Schreiber" <l.s.rock...@web.de> wrote: >>> Hello, >>> >>> I created an ipcore opb2ip_bridge (with edk's wizard) interfacing the >>> opb and added it to the edk reference design. So far, so good. While >>> running generate bitstream, synthesis stage runs through, but >>> implementation stage aborts immediately with ERROR:NgdBuild:604. >>> >>> --------------------------- >>> logfile excerpt: >>> ERROR:NgdBuild:604 - logical block >>> 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleA_0' with type >>> 'moduleA' could not be resolved. A pin name misspelling can cause this, >>> a missing edif or ngc file, or the misspelling of a type name. Symbol >>> 'moduleA' is not supported in target 'virtex2p'. >>> >>> ERROR:NgdBuild:604 - logical block >>> 'opb2ip_bridge_0/opb2ip_bridge_0/USER_LOGIC_I/moduleB_0' with type >>> 'moduleB' could not be resolved. A pin name misspelling can cause this, >>> a missing edif or ngc file, or the misspelling of a type name. Symbol >>> 'moduleB' is not supported in target 'virtex2p'. >>> --------------------------- >>> >>> My userdefined ipcore is unitized in a hierarchy of vhdl modules like: >>> >>> -opb2ip_bridge >>> |-USER_LOGIC >>> ||-moduleA >>> ||-moduleB >>> |||-moduleA >>> >>> Could this be the reason for the error. If so, is there any >>> configuration file, I would have to modify previously to make the >>> synthesis/ implementation stage be aware that my ipcore is designed >>> modular and how to resolve the symbol names. >>> >>> Or what is the real problem and how do I have to solve it. >>> >>> I'm working under edk and ise version 8 and latest service packs. The >>> reference design is not the problem, because it's already working in >>> other designs. >>> >>> Thanks for you help. >>> Greetings, Lars. >> >> >> I've seen something similar with COREgen modules in mixed language >> designs. > No, it's a vhdl only design. > >> Is moduleB a black box? > No, there are no black-box attributed instances inside the peripheral ip > design. > >> Do you have a .ngc file created for moduleB? > No, it doesn't seem, that the edk has built ngc files for the submodules > of the ip while executing "generate bitstreams" . Inside the > implementations directory there is only a opb2ip_0_wrapper.ngc for the > toplevel of my ipcore besides all the ngc files from the reference design. > >> Is it in the project directory? > My ip lies inside an external ip repository and is linked into the edk > reference design project. > >> If you answer yes to all three questions, then there is the >> possibility >> that ISE is looking for your .ngc code in another file such as >> moduleB_0.ngc due to the hierarchy created. In that case copying >> moduleB.ngc to moduleB_0.ngc can fix the problem. >> >> The same would apply to moduleA. >> >> HTH, >> GaborArticle: 123772
Weng, First you don't like using additional signals (one signal per conditional expression), and using the same signal in the condition as the assertion. So I demonstrate that additional signals are not necessary. I never said that using duplicate expressions to avoid additional signals/variables was a good idea, I just showed you how you could use them to avoid your dreaded extra signals (which, by the way, is almost always more self-documenting than the expression, even if it is not used in more than one place). It really isn't hard to use arrays and loops if you think about it. Most data bus driving circuits are based on decoding some sort of address with qualifiers (read_enable, etc.). Therefore I have as inputs either the address and enable, or I pre-decode (for timing reasons) the address into an array of strobes. Thus there are not separate lines for assigning array elements with individual signals, because I avoid the individual signals in the first place. Even if there are individual signals, they are often passed in on ports. Rather than have individual ports for the individual signals, I have an array port, with the signals bound to elements of the array port in the instantiation. No more code required to use an array than individual signals, and even less code in the entity declaration. I used to design fpgas with a big, centralized address decode module. That leads to lots of individual signals. Now I distribute the address and enables to individual modules, along with a generic for base address, etc. and let each module decode its own enables and determine when to drive the data bus with what. I also use a lot of tri-state logic that gets converted to multiplexers automatically, simply because it lets me decentralize the data bus loading. This also has the added benefit that the synthesis tool automatically assumes that the tri-state enables are mutually exclusive (otherwise the simulation would not have worked anyway), and optimizes the multiplexers automatically. You have to think about avoiding the individual signals in the first place, not just how to convert them into arrays. AndyArticle: 123773
On Aug 30, 8:41 am, Gabor <ga...@alacron.com> wrote: > On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote: > > > > > > > On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote: > > > > Hi all, > > > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB > > > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as > > > possible the DDR termination presents a problem. Since the Spartan3E > > > does not have DCI, termination on chip is not possible. This means > > > that 44 termination resistors should be added and maybe a VTT power > > > source. The other problem is that according to MIG we should connect > > > DDR to two banks. > > > > Any good suggestions? > > > Is it possible to eliminate termination resistors? > > > > Cheers, > > > > Guru > > > If you're only driving a single chip with very short lines you > > can probably get away without termination on everything except > > the clock. I would suggest using SSTL2_I instead of SSTL2_II > > to avoid overdriving. Another approach is to just leave out > > the series termination on these signals and just add the parallel > > termination to Vtt. I've used the latter method with Virtex2 > > and an SO-DIMM without DCI on the data lines and SSTL2_I drive. > > A good argument for leaving out the series termination is any > > net where the driving stub (from the S3 to the resistor) is > > about the same length as the driven stub (from the resistor > > to the memory). Here the terminator is of dubious value. > > > It's probably best to simulate your transmission lines, > > especially if you're planning to run the memory at its > > maximum speed of 166 MHz / DDR333. My V2 design ran at > > 133 MHz / DDR266. > > > HTH, > > Gabor > > One other thought if your main interest is in reducing the > board size. Often I find that using a x32 single-data-rate > (143 MHz) memory can save space. If you're using a TSSOP-66 > package for the DDR part, the 86-pin TSSOP for the x32 SDR > part has the same footprint and runs from +3.3V with no > requirements for VREF and DQS pins on the FPGA and no > Vtt or 2.5V supply. How looks the Vref signal inside the DDR II ? Exactly what is good for ? thx, VasileArticle: 123774
On Sep 1, 7:44 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Thu, 30 Aug 2007 15:36:04 +0100, "Symon" <symon_bre...@hotmail.com> > wrote: > > > > > > >"maxascent" <maxasc...@yahoo.co.uk> wrote in message > >news:ifidnQIYxf3YUUvbRVn_vw@giganews.com... > > >> Hi > > >> If I am designing a pcb using impedance controlled layers can I treat the > >> power planes as a reference layer as well as the gnd layers? > > >> Cheers > > >> Jon > > >Hi Jon, > >Yes. But with a caveat. When your signals switch reference layers, make sure > >there is a path for the reference current. > > >E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes > >from layer 1 to 6 through a via, you should have a bypass cap bewteen power > >and ground near this via. > > That's not necessary. There's already so much plane-plane capacitance > that the planes are already equipotential as far as the tiny charge > injected by the signal trace can affect them. > > Really, on a board with, say, 3000 vias, are you going to put a bypass > via near every signal via? I've heard of people asking for two! If you're routing a long 3Gbps differential signal, then definitely you must have ground vias near every signal pair vias. Bypassing with a capacitor near an inductive vias has no effect. But using at least one ZBC plane in the stack it helps. Vasile
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