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
On Jan 29, 4:38=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 28 Jan 2009 11:56:48 -0800 (PST), jleslie48 wrote: > >constant TstData : string(0 to 15) :=3D "Testing 1, 2, 3!"; > > A VHDL language-lawyer thing that will probably hit you > as soon as you try to use a professional-grade simulator: > > The built-in data type "string" is defined as > =A0 =A0type string is array (positive range <>) of character; > and "positive" is > =A0 =A0subtype positive is integer range 1 to INTEGER'HIGH; > > So a string indexed from 0 is technically illegal. =A0I'm > a little surprised that the tools you've already tried > allowed you to get away with it, but there's no doubt that > synthesis tools (and particularly FPGA vendor tools) are > a tad sloppy about things like that. No, Jonathan (the other one) did it correctly. I haven't worked with strings since the last time I did a test bench and I forgot about the indexing, or maybe I have never tried to index a string and just didn't know. Come to think of it, I am pretty sure I have never needed to index into a string. It would really bug me to have to use 1 based indexing for strings in synthesized code. But like I was saying elsewhere, optimization really should be left for the cases where it is worth the cost. > You can write > =A0 constant TstData: string (1 to 16) :=3D ... > or even (eccentrically) =A0 > =A0 ... string (16 downto 1) ... > but you must not include 0 in the subscript range. > > Note, too, that you don't need to specify the > subscript range for an array constant: > =A0 constant TstData: string :=3D "Testing"; > will automatically give TstData the range (1 to 7). > > You can then make your counter track the size > of the constant automatically like this: > > =A0 signal StrPtr: integer range TstData'range; > =A0 ... > =A0 =A0 =A0if reset =3D '1' then > =A0 =A0 =A0 =A0StrPtr <=3D TstData'low; > =A0 =A0 =A0elsif rising_edge(clock) then > =A0 =A0 =A0 =A0 if (it's time to increment the pointer) then > =A0 =A0 =A0 =A0 =A0 if StrPtr =3D TstData'high then > =A0 =A0 =A0 =A0 =A0 =A0 =A0StrPtr <=3D TstData'low; > =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0StrPtr <=3D StrPtr + 1; > =A0 =A0 =A0 =A0 =A0 end if; Do you know how this will synthesize? If my string is 1 to 4, will the counter be two bits or three? I think I know the answer, it will be three. Otherwise the hardware would not match the simulation. Good thing I don't normally use strings in synthesis. RickArticle: 137776
On Jan 29, 5:03=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
>
> (snip)
>
> >>> A word of warning regarding tristates (If you already know about how
> >>> tristates can cause simulation/synthesis mismatch you can stop readin=
g
> >>> now.) ?Consider the following VHDL code:
>
> (previous snip of verilog code)
>
> I believe verilog doesn't have this problem. =A0You will get X
> if you use Z with most operators. =A0&& and || will not give
> X if the other operand is 0 or 1 respectively, but that should
> also synthesize correctly.
I believe the same is true for VHDL. But the code above is not using
an operator. It is using a conditional assignment based on an IF.
o2_int <=3D '1';
if o1_int =3D '1' then
o2_int <=3D '0';
end if;
The IF evaluates the signal literally. If it is a '1', then o2_int
gets '0'. If it is ***any*** other value o2_int retains '1'.
> > <snip>
> >> The only time I can think of using a tristate internally in an FPGA is
> >> when very old code is being reused. =A0In that case I would expect the
> >> code to be rewritten to replace the tristate buffers with
> >> multiplexers. =A0Has this come up in your career?
>
> Multiplexers, or AND/OR logic. =A0But if the logic is easier
> to describe in tristate form, that should be fine. =A0
I would not use tristate logic, partly because of the problem Andreas
points out, but mainly because it can be confusing and misleading. I
think it is much better to change the code to match the current
devices than to retain the code in an obsolete form. I don't think
there are any issues of "but this code works"! If you are porting it
to a new device and most likely new tools, it has to be verified from
scratch anyway. So fixing the out of date code would not add
significantly to the cost.
> > Some students I supervised did this and had a very hard time debugging =
it.
> > They had probably read somewhere that the tools could convert tri-state=
s
> > to regular logic automatically and thought that was pretty neat. But th=
e
> > text that told them that the synthesis tool could do this probably neve=
r
> > warned them about simulation/synthesis mismatch. (I could also rant abo=
ut
> > the FPGA book they had borrowed from the library which had a UART examp=
le
> > that had more than one clock IIRC... *GRR*)
>
> There used to by systems with different transmit/receive speed
> (modems with 75 baud one direction, 1200 the other). =A0That would
> need separate send/receive clocks.
There is no reason why that would require different speed clocks;
different speed clock enables maybe, but it can and should run on a
single clock unless there is some compelling reason not to.
> > This is one of the reasons why I always try to warn people about this
> > kind of issue whenever I see someone suggesting that it is ok to use
> > tri-states inside an ASIC or FPGA because the tools can convert it to
> > regular logic.
>
> or use verilog.
;^)
> > The other reason is the same as the one you just described. It is
> > probably much better to model what you really want rather than modellin=
g
> > something you believe that the synthesis tool will probably be able to
> > translate into the thing you want.
The voice of reason...
Rick
Article: 137777On Thu, 29 Jan 2009 03:48:56 -0800 (PST), rickman wrote: >No, Jonathan (the other one) did it correctly. Rick, please check your facts. The line of code constant S: string (0 to 3) := "0123"; WILL NOT COMPILE in any standards-compliant tool. I can believe that some synthesis tools bend the rules and permit 0-based indexing of strings, but they should not. >It would really bug me to have to use >1 based indexing for strings in synthesized code. It bugs me too, but rules is rules. It is quite unusual to use strings in synthesis, partly because some older synthesis tools didn't handle CHARACTER data, but it works now in all the tools I've seen, so no reason why we shouldn't go ahead - correctly. >optimization really should be left for the cases >where it is worth the cost. It's nothing to do with optimization; if the code is illegal, optimization doesn't happen. [snip legal example] >Do you know how this will synthesize? If my string is 1 to 4, will >the counter be two bits or three? I think I know the answer, it will >be three. I completely agree with you. If you are so desperate to have a counter that's one bit shorter, you could easily define your own new string type type stringZ is array (natural range <>) of character; and use that - but, of course, you would then lose all the built-in TEXTIO functionality that is so useful in testbenches. -- 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: 137778
On Jan 28, 8:07 pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 28 Jan 2009 13:26:20 -0800 (PST), jleslie48 > > <j...@jonathanleslie.com> wrote: > >I switch 'sources for' from implementation to 'behavioral > >simulation' > ... > >Project Navigator will create a new skeleton source with the following > >spec: > >Add to Project: Yes > >Source Directory: C:\jon > >\fpga_uarted_01\2009_01_26\LOKI_New_H_Project_VHDL\Code_Versions\10 - > >New_Xilinx_Wrap_Data\LOKI_Top > >Source Type: VHDL Test Bench > >Source Name: abcd.vhd > > >Association: LOKI_TOP > > all that looks OK and you FOUND the simulator page (took me a while!). > Which sim do you have? ISE sim or Modelsim? > > ... but the question is, when>I click finish, > > what happens in the console window at the bottom? I see the > UnitUnderTest being compiled so that the wizard knows how to wire it up > for testing. Is that compilation failing? Might explain the problem. > > Or, if the wizard won't play, just "add copy of source" a testbench from > one of the example projects into your project and edit it to suit. > > - Brian > (LOKI? He's our cat!) sim is ISE but the original behavorial simulation was done using Modelsim, and I think its confused. not a thing is showing up in the console window at the bottom quiet as a mouse. that is consistent with the fact that abcd.vhd was never created either. Loki - god of mischef.Article: 137779
On Jan 29, 12:35 am, rickman <gnu...@gmail.com> wrote:
> I have to say that I find your learning process to be very
> interesting. It has been so long for me that I have forgotten exactly
> what it was that I had to learn or unlearn to switch from software to
> HDL. I am getting a feel for that again.
>
> On Jan 28, 2:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > Ok,
>
> > continuing with the RS232 and Ricks pseudo code for sending out a 16
> > character message:
> > --------------------------------------------------------------------------------
> > constant TstData : string(0 to 15) := "Testing 1, 2, 3!";
> > signal TxCntr : integer range 0 to 16;
>
> > TxNxtData <= TstData (TxCntr);
>
> > -- Data source control, provide string data to the UART, repeat every
> > 16 chars
> > process SelectCntr ( clk, reset ) is
> > begin
> > if (reset = '1') then
> > TxCntr <= 0;
> > elsif ( rising_edge (clk) ) then
> > if ( TxRdy = '0' ) then
> > TxWrite <= '0';
> > else
> > if ( TxWrite = '0' and TxCntr <> 16 ) then
> > TxWrite <= '1';
> > TxCntr <= TxCntr + 1;
> > end if;
> > end if;
> > end if;
> > end process;
>
> > ---------------------------------------------------------------------------------
>
> > I cleaned this up a bit, used my variable names, to get a synth to
> > work:
> > ----------------------------------------------------------------------
>
> > function to_slv(c: character) return std_logic_vector is
> > begin
> > return std_logic_vector(to_unsigned(character'pos(c), 8));
> > end;
>
> > SIGNAL system_startup : STD_LOGIC := '1';
> > SIGNAL txwrite : STD_LOGIC := '1';
> > SIGNAL txrdy : STD_LOGIC := '0';
> > SIGNAL TxNxtData : STD_LOGIC_VECTOR( 7 downto 0 );
> > SIGNAL init_done : STD_LOGIC := '0';
> > signal TxCntr : integer range 0 to 17;
>
> > constant TstData : string(1 to 16) := "Testing 1, 2, 3!";
>
> > TxNxtData <= to_slv(TstData(TxCntr));
>
> > -- Initialize01
> > --
> > -- Lets put out a hello world message once when the system first
> > starts up,
> > --
> > -- system_startup, init_done are flags to start the run and signal th
> > end.
> > -- txrdy and txwrite, do some ping_pong thing to get the chars out I
> > think.
> > -- lets see.
> > --
> > initialize01: process ( CLK_16_6MHZ, system_startup )
> > begin
> > if (system_startup = '1') then --1{
> > TxCntr <= 1;
> > system_startup <= '0';
> > init_done <= '0';
> > TxRdy <= '0';
> > elsif ( rising_edge (CLK_16_6MHZ) ) then --1
> > if ( TxRdy = '0' ) then --5{
> > TxWrite <= '0';
> > else
> > if ( TxWrite = '0' and TxCntr /= 17 ) then --4{
> > TxWrite <= '1';
> > TxRdy <= '0';
> > TxCntr <= TxCntr + 1;
> > if (init_done = '0') then --3{
> > TX_DATA_IN <= TxNxtData ;
> > end if; --3}
> > elsif (TxCntr = 17) then --4
> > init_done <= '1';
> > end if; --4}
> > end if; --5}
> > end if; --1}
> > end process initialize01 ;
> > ----------------------------------------------------------------------
>
> > the act of getting through the syntax errors was very useful,
> > particularly since
> > when I added the >>>TX_DATA_IN <= TxNxtData ;<<< line
> > I got 8 errors relating to "multiple line drive" or something to that
> > effect.
>
> > Well you guys beat it into my head enough times, and instantly
> > realized that and I had
> > two wires hooked up to TX_DATA_IN that could both send in signals at
> > the same time, and
> > that would be a no-no. That is when I added the "init_done" boolean
> > both here and in the
> > regular transmission producer, process p7 which I renamed to the more
> > appropriate, uart_echo:
> > ________________________
>
> > --p7
> > uart_echo: PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER,
> > RX_READ_BUFFER_STB, RX_DATA_OUT( 7 DOWNTO 0 ) )
> > BEGIN
> > IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
> > IF ( UART_RESET_BUFFER = '0' ) THEN
> > IF ( RX_READ_BUFFER_STB = '1' ) THEN
> > if ( init_done = '1') then
> > TX_DATA_IN <= RX_DATA_OUT;
> > end if;
> > END IF;
> > END IF;
> > END IF;
> > END PROCESS uart_echo;
> > __________________________
>
> > note the TX_DATA_IN line is now dependent on the init_done flag.
>
> > well then after being all proud of my synth coming up clean (well no
> > errors, and 23 warnings, I didn't say spotless...) I actually took the
> > plunge and loaded up my board and ran it.
>
> > Yuck.
>
> > no hello world message, and even the uart_echo is now broken.
>
> > So, taking the advise I was given here, its time to testbench this
> > puppy and see what all my system_startup, init_done, etc are doing.
> > Lets see if I can make up a good testbench to this thing,
>
> Yeah, I have no idea why the change you made to add init_done would
> have gotten rid of the "multiple line drive" error. If you make an
> assignment to a signal within a process, that is defining some sort of
> driver on that signal. If you make assignments to the same signal
> from two different processes, that puts two drivers on the same signal
> and creates a problem.
>
> This is another error of thinking like software rather than hardware.
> The fact that the two assignment statements are not made under the
> same conditions does not make this work any better. It is
> "describing" two registers with their outputs tied together and that
> will not work. You need a multiplexer to select either the test data
> or the receiver data register. Try replacing the uart_echo process
> with a concurrent statement...
>
> TX_DATA_IN <= TxNxtData when (init_done = '0') else RX_DATA_OUT ;
>
> Notice that I also removed the assignment to TX_DATA_IN from the
> initialize01 process. That was adding a register to the data path
> that is not needed. The character counter, TxCntr, provides a select
> value to control a mux on the character array. Actually, this logic
> is combined and optimized to produce the TxNxtData without actually
> having an array of chars and a mux, but that is not important. The
> output of this mux is appropriately timed by the changes in TxCntr so
> that it can directly drive the UART Tx input, TX_DATA_IN.
>
> Just as a matter of style, init_done also does not need to be in the
> clocked process. Any signal assigned in a clocked process produces a
> register. init_done only needs to be the decode of the state of
> TxCntr = 17. Or even simpler is to use 0 to 15 on the string constant
> and to use 16 as the terminal state which brings me to the use of
> integers. Again this is an issue of preference, but you can use
> signed or unsigned from the ieee.numeric_std package. These types are
> related to slv so that they can convert without a conversion
> function. They are arrays, so you can pick out individual bits. I
> have all but done away with integers myself. Then picking out the msb
> of TxCntr would be init_done <= TxCntr (4); as a concurrent
> assignment.
>
> A final thought. The dual assignment to TX_DATA_IN should be
> producing an error. It will cause an 'X' to be displayed on that
> signal in the simulator... or at least it should. It may be a 'U',
> I'm not certain. But it won't work correctly until you change the
> code.
>
> If you had to draw a diagram of the registers in this design, would
> you be able to do that? If you can do that, you can then use
> templates to produce the code to match the register descriptions with
> very few errors.
>
> Rick
~ Yeah, I have no idea why the change you made to add init_done would
~ have gotten rid of the "multiple line drive" error.
I didn't expect it to work for similar reasons you expected it to
fail. It was
just my first attempt, It was nothing more than a software persons
first thought
at a solution, a mutex. Logically correct, but I was doubtful whether
it was
synthesizable. Your solution is much better:
~ TX_DATA_IN <= TxNxtData when (init_done = '0') else RX_DATA_OUT ;
this way TX_DATA_in is driven by a single mechanism.
~TX_DATA_IN <= TX_DATA_1 when init_done = '1' else
~ -- other data source when other condition else
~ TX_DATA_2;
~or combine both processes into one...
~NOTE - the first approach isn't actually supported in modern FPGAs.
~But you can safely use it - the tools do a good job of transforming
it
~into the equivalent second approach.
~>So, taking the advise I was given here, its time to testbench this
~>puppy and see what all my system_startup, init_done, etc are doing.
~>Lets see if I can make up a good testbench to this thing
~Testbench is well worth doing...
~also consider bringing out "init_done< to an external pin -
preferably
~with a LED on it...
Again a good idea (both of them) Testbench and ISE is being a
stubborn cluck,
I'm still fighting with it. I posted another thread on that dragon to
slay. I did
commandeer another testbench program and got it to start. It actually
"crashed"
when I launched it on an array out of bounds error. That was quite
useful actually.
I had txcntr declared wrong:
signal TxCntr : integer range 0 to 17;
instead of the correct:
signal TxCntr : integer range 1 to 17;
that 0 value must of made its way to the index of the string which got
mad.
it's been a long time (since pascal) that a language did that. It was
like a welcome
friend.
Meantime that testbench was designed for Modelsim, and the
system_clock didn't
even work. I'm still annoyed that the new source wizard is not doing
anything.
To be continued...
Article: 137780On 28 Jan 2009 17:30:27 -0500, DJ Delorie <dj@delorie.com> wrote: |> As for Linux based software, I have no knowledge of and therefore |> refused to comment on them as I do not run Linux. | |Geda+pcb runs on Mac and Windows as well. Kicad runs on Windows. So, |the fact that you don't run Linux is no excuse - go try them on |Windows :-) |============== I am sorry that you appear to be offended from my lack of inclusions. Maybe your favorite was not mentioned. I tend to comment on applications that I have used enough to make recommendations on. Right now my needs are well satisfied by the free version of Eagle. I am now retired and any boards I make for hobby use are generally well under 9 square inches in area. Furthermore I have yet to really need more than two routing layers. Now when I was employeed I routed up to 8 layers. Most often was four layers. I am aware of Kicad. It has promise just from initial look. I may consider it if I need larger boards and more routing layers. jamesArticle: 137781
On Thu, 29 Jan 2009 09:38:39 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Wed, 28 Jan 2009 11:56:48 -0800 (PST), jleslie48 wrote: > >>constant TstData : string(0 to 15) := "Testing 1, 2, 3!"; > >A VHDL language-lawyer thing that will probably hit you >as soon as you try to use a professional-grade simulator: > >The built-in data type "string" is defined as > type string is array (positive range <>) of character; >and "positive" is > subtype positive is integer range 1 to INTEGER'HIGH; > >So a string indexed from 0 is technically illegal. I'm >a little surprised that the tools you've already tried >allowed you to get away with it, but there's no doubt that >synthesis tools (and particularly FPGA vendor tools) are >a tad sloppy about things like that. XST is indeed surprisingly permissive where it can "understand" in hardware terms, something technically illegal. (Or thinks it can...) I suspect the thinking behind it is "we don't need to run those checks, because the source has obviously already passed simulation". Which is OK if you actually use it that way... - BrianArticle: 137782
On Thu, 29 Jan 2009 09:38:39 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: Forgot to say... "jleslie" - watch this bit... >Note, too, that you don't need to specify the >subscript range for an array constant: > constant TstData: string := "Testing"; >will automatically give TstData the range (1 to 7). > >You can then make your counter track the size >of the constant automatically like this: > > signal StrPtr: integer range TstData'range; > ... > if reset = '1' then > StrPtr <= TstData'low; > elsif rising_edge(clock) then > if (it's time to increment the pointer) then > if StrPtr = TstData'high then > StrPtr <= TstData'low; > else > StrPtr <= StrPtr + 1; > end if; > ... Nice example of using the type system to do ITS work (not your work!) for you. - BrianArticle: 137783
On Thu, 29 Jan 2009 03:13:16 +0000 (UTC), Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: >On 2009-01-29, Brian Drummond <brian_drummond@btconnect.com> wrote: >> NOTE - the first approach isn't actually supported in modern FPGAs. >> But you can safely use it - the tools do a good job of transforming it >> into the equivalent second approach. > > >A word of warning regarding tristates (If you already know about how >tristates can cause simulation/synthesis mismatch you can stop reading >now.) Well worth making the warning; it's difficult to know how much detail to load onto the poor guy! but he seems to take it in his stride... Just to add an alternative take on your warning, which will show why I didn't give it - in your example > o1_int <= foo1 when sel1 = '1' else 'Z'; > o1_int <= foo2 when sel2 = '1' else 'Z'; the problems really arise because your "sel" conditions may not be complete and mutually exclusive; hence you drive o1_int with 0, 1 or 2 sources... if you arrange complete and mutually exclusive sel conditions (for example, "a" and "not a") you really don't need to worry. - BrianArticle: 137784
james <george@washington.edu> writes: > I am sorry that you appear to be offended from my lack of inclusions. > Maybe your favorite was not mentioned. I tend to comment on > applications that I have used enough to make recommendations on. Not offended, just trying to correct some misunderstandings about open source software, that's all. It's a growing field outside of the unix/linux arena, and I wouldn't want people to miss out on something that might be useful to them just because they didn't think it would run in their environment. Definitely an up-hill battle, though.Article: 137785
On Jan 29, 9:40 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 29 Jan 2009 09:38:39 +0000, Jonathan Bromley > > <jonathan.brom...@MYCOMPANY.com> wrote: > > Forgot to say... > > "jleslie" - watch this bit... > > > > >Note, too, that you don't need to specify the > >subscript range for an array constant: > > constant TstData: string := "Testing"; > >will automatically give TstData the range (1 to 7). > > >You can then make your counter track the size > >of the constant automatically like this: > > > signal StrPtr: integer range TstData'range; > > ... > > if reset = '1' then > > StrPtr <= TstData'low; > > elsif rising_edge(clock) then > > if (it's time to increment the pointer) then > > if StrPtr = TstData'high then > > StrPtr <= TstData'low; > > else > > StrPtr <= StrPtr + 1; > > end if; > > ... > > Nice example of using the type system to do ITS work (not your work!) > for you. > > - Brian NIce. I know I have a lot of cleaning up to do.Article: 137786
On Jan 29, 4:38 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 28 Jan 2009 11:56:48 -0800 (PST), jleslie48 wrote: > >constant TstData : string(0 to 15) := "Testing 1, 2, 3!"; > > A VHDL language-lawyer thing that will probably hit you > as soon as you try to use a professional-grade simulator: > > The built-in data type "string" is defined as > type string is array (positive range <>) of character; > and "positive" is > subtype positive is integer range 1 to INTEGER'HIGH; > > So a string indexed from 0 is technically illegal. I'm > a little surprised that the tools you've already tried > allowed you to get away with it, but there's no doubt that > synthesis tools (and particularly FPGA vendor tools) are > a tad sloppy about things like that. > > You can write > constant TstData: string (1 to 16) := ... > or even (eccentrically) > ... string (16 downto 1) ... > but you must not include 0 in the subscript range. > > Note, too, that you don't need to specify the > subscript range for an array constant: > constant TstData: string := "Testing"; > will automatically give TstData the range (1 to 7). > > You can then make your counter track the size > of the constant automatically like this: > > signal StrPtr: integer range TstData'range; > ... > if reset = '1' then > StrPtr <= TstData'low; > elsif rising_edge(clock) then > if (it's time to increment the pointer) then > if StrPtr = TstData'high then > StrPtr <= TstData'low; > else > StrPtr <= StrPtr + 1; > end if; > ... > -- > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Oh yeah, I just glossed over a lot of the syntax errors when I first implemented Ricks code. there were a bunch (/= instead of <>, eg) and the synth saw the declaration 0 to xxx as bad and flagged it as such. Since wet behind the ears me was able to figure those out, I didn't bother wasting your all time with the syntax stuff. But I do love the compile time derived constants, like TstData'range, TstData'low, high, etc. They will make updates to strings much less cumbersome. Is there a list of all these "common" words/concepts somewhere online? I mean I have a bunch of pdf's that have these very formal lists of "reserved words" but all of them seem to be missing the "reserved" words of the libraries. For example none of the lists show "rising_edge" and "string". I know they are not technically "reserved" words but for all practical purposes, one uses this set of <?????> as reserved words. You have just introduced <variablename>'low, 'high, 'range, I also should of recognized 'event (as in system_clock'event) as a member of this superset of reserved words.Article: 137787
On Jan 29, 12:35 am, rickman <gnu...@gmail.com> wrote: > I have to say that I find your learning process to be very > interesting. It has been so long for me that I have forgotten exactly > what it was that I had to learn or unlearn to switch from software to > HDL. I am getting a feel for that again. > So glad your enjoying yourself :)))))) Rata-fracken,summana,friken,thing-a-mabob....Article: 137788
On Jan 29, 9:48 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 29 Jan 2009 03:13:16 +0000 (UTC), Andreas Ehliar > Well worth making the warning; it's difficult to know how much detail to > load onto the poor guy! but he seems to take it in his stride... > Yes, I recognize when the conversation has gone off on an advanced topic; and stay clear of it until I'm at point where my input is more than "huh???" By all means continue, as I get more and more comfortable I imagine I will revisit these finer points.Article: 137789
On Thu, 29 Jan 2009 08:44:35 -0800 (PST), jleslie48 wrote:
>But I do love the compile time derived constants, like TstData'range,
>TstData'low, high, etc.
>They will make updates to strings much less cumbersome.
And many other things too.
>Is there a list of all these "common" words/concepts somewhere online?
Try this. It's not as good as our Golden Reference Guide
but it's online and free :-)
http://www.csee.umbc.edu/help/VHDL/VHDL-Handbook.pdf
They are "predefined attribute names" and the ones you
need to know about are:
- for array types, variables and signals:
'range -- the subscript range such as 7 downto 0
'low, 'high -- numerically lowest and highest index
'left, 'right -- leftmost, rightmost index
'length -- number of indices in the range
- for discrete types like INTEGER, NATURAL etc
(but NOT for objects of those types):
'range, 'low, 'high, 'left, 'right
- for any singular data type like enumerations,
CHARACTER, STD_LOGIC, integers:
'image, 'value (mainly for assertions and testbench)
These are FUNCTIONS that allow you to convert
things to/from a human-readable string representation.
So, for example, INTEGER'IMAGE(25) returns the string "25".
INTEGER'VALUE("1000") returns the integer 0.
Not a comprehensive list, but it covers most of the
routinely useful ones. Note these handy idioms:
-- make a clone of some other array
signal clone: std_logic_vector(original'range);
-- vector copy-compatible with "original", but
-- with its index range normalized to (N-1 downto 0)
variable normalized: std_logic_vector(original'length-1 downto 0);
-- loop over the elements of an array
for i in V'range loop
-- do something with V(i)
end loop;
>I mean I have a bunch of pdf's that have these very formal lists of
>"reserved words" but
>all of them seem to be missing the "reserved" words of the libraries.
As you correctly said, they're not reserved. The packages
define the names, and you import them by use-ing the package.
Too many to list here. Take a look at the packages the
next time you have ModelSim open, or get a copy of Peter
Ashenden's "Designer's Guide to VHDL", or go on a
training course :-0
--
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: 137790
On Jan 29, 12:08 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Thu, 29 Jan 2009 08:44:35 -0800 (PST), jleslie48 wrote:
> >But I do love the compile time derived constants, like TstData'range,
> >TstData'low, high, etc.
> >They will make updates to strings much less cumbersome.
>
> And many other things too.
>
> >Is there a list of all these "common" words/concepts somewhere online?
>
> Try this. It's not as good as our Golden Reference Guide
> but it's online and free :-)
>
> http://www.csee.umbc.edu/help/VHDL/VHDL-Handbook.pdf
>
> They are "predefined attribute names" and the ones you
> need to know about are:
>
> - for array types, variables and signals:
> 'range -- the subscript range such as 7 downto 0
> 'low, 'high -- numerically lowest and highest index
> 'left, 'right -- leftmost, rightmost index
> 'length -- number of indices in the range
>
> - for discrete types like INTEGER, NATURAL etc
> (but NOT for objects of those types):
> 'range, 'low, 'high, 'left, 'right
>
> - for any singular data type like enumerations,
> CHARACTER, STD_LOGIC, integers:
> 'image, 'value (mainly for assertions and testbench)
> These are FUNCTIONS that allow you to convert
> things to/from a human-readable string representation.
> So, for example, INTEGER'IMAGE(25) returns the string "25".
> INTEGER'VALUE("1000") returns the integer 0.
>
> Not a comprehensive list, but it covers most of the
> routinely useful ones. Note these handy idioms:
>
> -- make a clone of some other array
> signal clone: std_logic_vector(original'range);
>
> -- vector copy-compatible with "original", but
> -- with its index range normalized to (N-1 downto 0)
> variable normalized: std_logic_vector(original'length-1 downto 0);
>
> -- loop over the elements of an array
> for i in V'range loop
> -- do something with V(i)
> end loop;
>
> >I mean I have a bunch of pdf's that have these very formal lists of
> >"reserved words" but
> >all of them seem to be missing the "reserved" words of the libraries.
>
> As you correctly said, they're not reserved. The packages
> define the names, and you import them by use-ing the package.
>
> Too many to list here. Take a look at the packages the
> next time you have ModelSim open, or get a copy of Peter
> Ashenden's "Designer's Guide to VHDL", or go on a
> training course :-0
> --
> 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
-------------------------
> Too many to list here. Take a look at the packages the
> next time you have ModelSim open, or get a copy of Peter
> Ashenden's "Designer's Guide to VHDL", or go on a
> training course :-0
your list of the "good" ones is fine thanks. and the
term "predefined attribute names" for these is great.
but there are more. For example, "string" is a library type I'm
guessing,
and for all practical purposes works just like the rest of my
"super-set of reserved words/predefined attribute names/procedures/
functions/goodies"
> but it's online and free :-)
>
> http://www.csee.umbc.edu/help/VHDL/VHDL-Handbook.pdf
>
LOL, that is exactly the pdf I was looking at when I composed my post
about
the reserved words list needs to be more inclusive ....
Article: 137791On Thu, 29 Jan 2009 09:34:03 -0800 (PST), jleslie48 wrote: >> but it's online and free :-) >> >> http://www.csee.umbc.edu/help/VHDL/VHDL-Handbook.pdf >> > >LOL, that is exactly the pdf I was looking at >when I composed my post about >the reserved words list needs to be more inclusive .... sheesh, I hate doing sales on the NG but you give me no choice... for the cost of less than of half-an-hour of a contractor's time you can have one of our GRGs and get a bunch of hints and tricks as well as the lists of what-have-you that you seek... www.doulos.com/content/products/golden_reference_guides.php with apologies to everyone else for the spam! -- 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: 137792
secureasm@gmail.com wrote:
>Hi Gabor,
>
>
>> I don't know what your budget is, but if you're completely
>> inexperienced and have the money, you may want to consider
>> using a design service. =A0We use a local service who consistently
>> gives us the lowest price on design projects. =A0
>
>I have some experienced with OrCAD, only two layer, manul route
>processing never used autoroute.
>
>> He uses PADS
>> software and only autoroutes non-critical nets. =A0I have
>> the PADS viewer which allows me to check his design output
>> and run off Gerber files for production. =A0A full seat of
>> PADS (without autorouting) starts around $5,000.00 but
>> you can get a free evaluation copy that is limited in
>> the size of design you can produce, if you want to play
>> around with it first.
>
>PADs software from Mentor Graphics ?
>
>I have to start a new project with an FPGA, therefore you must use a
>multilayer PCB. I was wondering if anyone of you use systems, with
>automatic systems routing. I do not even imagine how you can manually
>route 600 or more tracks on multilayer PCB.
That is not so difficult as it seems. Drawing the tracks is 20% of the
work involved in making a PCB. The work on the PCB starts before
creating the circuit diagram. You'll need to get an idea on where the
major components and connectors are located (perhaps create a dummy
PCB design with the major components). Think about where sensitive
stuff goes, where the power supply is located, etc, etc. From this you
can make good choices on how to connect pins with a freely
programmable function.
The next step is to get all the footprints 100% right. Make sure you
draw the footprint outline (silkscreen) exactly according to the sizes
mentioned in the datasheet. There is nothing worse than finding out
two components are too close together (won't fit) because the outline
was drawn wrong. Also include clear markings for pin 1, +, kathode,
etc.
Then you need to find out what clearances, traces width, hole sizes,
anular rings your board manufacturor supports. One of the major
problems here is that some board manufacturors interpret the holes as
the final holes sizes after plating and others interpret them as the
holes sizes before plating. With small vias this does make a big
difference. You'll need to setup your PCB project to have the proper
clearances and hole sizes.
To get to the autorouter part: Most people I know draw traces by hand.
In the early days an autorouter could route a PCB with thru-hole DIP
packages without much problems. I used to do this a lot to save time,
but it took me quite some effort to learn how to use the autorouter.
Nowadays I route by hand.
With SMD the simple autorouters won't work. However, I'm quite sure a
modern autorouter is capable of routing a SMD PCB but I'm also quite
sure it will take a 3 to 5 day course to learn how to configure the
autorouter so it won't produce crap.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137793
DJ Delorie <dj@delorie.com> wrote:
>
>james <george@washington.edu> writes:
>> In that case you are going to need a layout program that supports at
>> least 8 routing layers. In the $1000 range there is Eagle without
>> the autorouter. $1500 with autorouter. Eagle Pro will do 16 route
>> planes.
>
>You forgot about the $0 range - most free software EDA programs don't
>put arbitrary limits on board layouts. PCB, for example, supports 16
>layers as-is, but can be recompiled for as many as you need, and has
>no limits on number of pins/pads or size of board. It comes with a
>free autorouter too. I don't know what KiCad's limits are, but I'm
>guessing it can do all that also.
DJ just a side question: is there a version of PCB that runs on
Windows?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137794
james <george@washington.edu> wrote:
>On 28 Jan 2009 17:30:27 -0500, DJ Delorie <dj@delorie.com> wrote:
>
>|> As for Linux based software, I have no knowledge of and therefore
>|> refused to comment on them as I do not run Linux.
>|
>|Geda+pcb runs on Mac and Windows as well. Kicad runs on Windows. So,
>|the fact that you don't run Linux is no excuse - go try them on
>|Windows :-)
>|==============
>
>I am sorry that you appear to be offended from my lack of inclusions.
>Maybe your favorite was not mentioned. I tend to comment on
>applications that I have used enough to make recommendations on.
>
>Right now my needs are well satisfied by the free version of Eagle. I
>am now retired and any boards I make for hobby use are generally well
>under 9 square inches in area. Furthermore I have yet to really need
>more than two routing layers. Now when I was employeed I routed up to
>8 layers. Most often was four layers.
>
>I am aware of Kicad. It has promise just from initial look. I may
>consider it if I need larger boards and more routing layers.
I tried Kicad. Waste of my time. Editing tracks is a real nightmare.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137795nico@puntnl.niks (Nico Coesel) writes: > DJ just a side question: is there a version of PCB that runs on > Windows? Yes. It's on the sourceforge download page, just make sure you download the .exe and not the .tar.gz ;) http://pcb.sourceforge.net/Article: 137796
rickman wrote: > The lesson I learned however, was that if you don't really need to > optimize an FPGA design, DON'T! This is the best advice in this entire thread. HDL synthesis of FPGA primitives is complicated, and has many dependencies. I might be able to be save a LUT or a nS in a trivial example, but I would always bet with ise or quartus for the full design. The only thing I *expect* of the synthesis netlist is that it sims the same as my HDL code and STA is accurate. -- Mike TreselerArticle: 137797
On Jan 28, 7:45=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > nna...@terra.es wrote: > > > INCREDIBLE!! > > the problem was originated by the PCB. There was some resistance or > > short circuit in the bus lines wich hangued the cpu and possibly > > destroyed the XCS05. > > With a 5V supply between the line and GND we eliminated the shorts but > > appeared after few minutes. We try to measure the resistance of the > > lines with a tester and found to be lower and lower, accelerating the > > decrease if we heated the PCB. Anybody knows the explanation of that ? > > thank you > > =BFWas the PCB designed by rogue clowns? =BFFor great justice? Check the = eel > capacity of your hovercraft. We once had a bad lot of PC boards that had problems with connections disappearing after time or with temperature, but there are failure modes that could cause shorts to develop over time as well. If the short is in an inner layer, it could be due to incomplete processing (rinsing) before lamination. On a surface layer this sort of short can happen from use of water-soluble flux that isn't properly rinsed. We had issues with flux eating surface layer etch when the rinse did not clear all the flux under very thin components.Article: 137798
On Jan 29, 8:00=A0am, jleslie48 <j...@jonathanleslie.com> wrote: > On Jan 28, 8:07 pm, Brian Drummond <brian_drumm...@btconnect.com> > wrote: > > > > > On Wed, 28 Jan 2009 13:26:20 -0800 (PST), jleslie48 > > > <j...@jonathanleslie.com> wrote: > > >I switch 'sources for' from =A0implementation to 'behavioral > > >simulation' > > ... > > >Project Navigator will create a new skeleton source with the following > > >spec: > > >Add to Project: Yes > > >Source Directory: C:\jon > > >\fpga_uarted_01\2009_01_26\LOKI_New_H_Project_VHDL\Code_Versions\10 - > > >New_Xilinx_Wrap_Data\LOKI_Top > > >Source Type: VHDL Test Bench > > >Source Name: abcd.vhd > > > >Association: LOKI_TOP > > > all that looks OK and you FOUND the simulator page (took me a while!). > > Which sim do you have? ISE sim or Modelsim? > > > ... but the question is, when>I click finish, > > > what happens in the console window at the bottom? I see the > > UnitUnderTest being compiled so that the wizard knows how to wire it up > > for testing. Is that compilation failing? Might explain the problem. > > > Or, if the wizard won't play, just "add copy of source" a testbench fro= m > > one of the example projects into your project and edit it to suit. > > > - Brian > > (LOKI? He's our cat!) > > sim is ISE but the original behavorial simulation was done using > Modelsim, > and I think its confused. > > not a thing is showing up in the console window at the bottom quiet as > a mouse. > that is consistent with the fact that abcd.vhd was never created > either. > > Loki - god of mischef. Did you look for the file in your project directory? Which view did the source not appear in? Normally testbenches only appear in the view for "Behavioral Simulation", not the "Synthesis" view (default).Article: 137799
On Jan 29, 3:18 pm, Gabor <ga...@alacron.com> wrote:
> On Jan 29, 8:00 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Jan 28, 8:07 pm, Brian Drummond <brian_drumm...@btconnect.com>
> > wrote:
>
> > > On Wed, 28 Jan 2009 13:26:20 -0800 (PST), jleslie48
>
> > > <j...@jonathanleslie.com> wrote:
> > > >I switch 'sources for' from implementation to 'behavioral
> > > >simulation'
> > > ...
> > > >Project Navigator will create a new skeleton source with the following
> > > >spec:
> > > >Add to Project: Yes
> > > >Source Directory: C:\jon
> > > >\fpga_uarted_01\2009_01_26\LOKI_New_H_Project_VHDL\Code_Versions\10 -
> > > >New_Xilinx_Wrap_Data\LOKI_Top
> > > >Source Type: VHDL Test Bench
> > > >Source Name: abcd.vhd
>
> > > >Association: LOKI_TOP
>
> > > all that looks OK and you FOUND the simulator page (took me a while!).
> > > Which sim do you have? ISE sim or Modelsim?
>
> > > ... but the question is, when>I click finish,
>
> > > what happens in the console window at the bottom? I see the
> > > UnitUnderTest being compiled so that the wizard knows how to wire it up
> > > for testing. Is that compilation failing? Might explain the problem.
>
> > > Or, if the wizard won't play, just "add copy of source" a testbench from
> > > one of the example projects into your project and edit it to suit.
>
> > > - Brian
> > > (LOKI? He's our cat!)
>
> > sim is ISE but the original behavorial simulation was done using
> > Modelsim,
> > and I think its confused.
>
> > not a thing is showing up in the console window at the bottom quiet as
> > a mouse.
> > that is consistent with the fact that abcd.vhd was never created
> > either.
>
> > Loki - god of mischef.
>
> Did you look for the file in your project directory? Which
> view did the source not appear in? Normally testbenches only
> appear in the view for "Behavioral Simulation", not the
> "Synthesis" view (default).
yeah I tried that, even did a search of the entire C:\ drive
it didn't make it.
I have solved the problem though. It's a bug in ISE 10.1.103
It simply will not let you re-run new source-->vhdl test bench
once you have done it once under modelsim and then switch the
properties to ISE simulator. I don't know if the problem has other
variations.
To get around the problem I made a brand new project from scratch
stating from the get go ISE Simulator. Added all the sources, SIG'ed
it (Syntesize, Implement, Generate) then switched to Behavioral
Simulation view,
added new source-->vhdl test bench ... and then it worked, actually
made the
testbench program:
-----------------------------------------------
--------------------------------------------------------------------------------
-- Company:
-- Engineer:
--
-- Create Date: 14:27:37 01/29/2009
-- Design Name:
-- Module Name: C:/jon/fpga_uarted_01/2009_01_28_jl_mod/11jlmod/
ccuart01/source/loki_top_tb.vhd
-- Project Name: ccuart01
-- Target Device:
-- Tool versions:
-- Description:
--
-- VHDL Test Bench Created by ISE for module: LOKI_TOP
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
-- Notes:
-- This testbench has been automatically generated using types
std_logic and
-- std_logic_vector for the ports of the unit under test. Xilinx
recommends
-- that these types always be used for the top-level I/O of a design
in order
-- to guarantee that the testbench will bind correctly to the post-
implementation
-- simulation model.
--------------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.ALL;
ENTITY loki_top_tb IS
END loki_top_tb;
ARCHITECTURE behavior OF loki_top_tb IS
-- Component Declaration for the Unit Under Test (UUT)
COMPONENT LOKI_TOP
PORT(
SYSTEM_CLOCK : IN std_logic;
RS232_DSR_OUT : OUT std_logic;
RS232_TX_DATA : OUT std_logic;
RS232_CTS_OUT : OUT std_logic;
RS232_RX_DATA : IN std_logic;
LED_0 : OUT std_logic;
LED_1 : OUT std_logic;
LED_2 : OUT std_logic;
LED_3 : OUT std_logic
);
END COMPONENT;
--Inputs
signal SYSTEM_CLOCK : std_logic := '0';
signal RS232_RX_DATA : std_logic := '0';
--Outputs
signal RS232_DSR_OUT : std_logic;
signal RS232_TX_DATA : std_logic;
signal RS232_CTS_OUT : std_logic;
signal LED_0 : std_logic;
signal LED_1 : std_logic;
signal LED_2 : std_logic;
signal LED_3 : std_logic;
BEGIN
-- Instantiate the Unit Under Test (UUT)
uut: LOKI_TOP PORT MAP (
SYSTEM_CLOCK => SYSTEM_CLOCK,
RS232_DSR_OUT => RS232_DSR_OUT,
RS232_TX_DATA => RS232_TX_DATA,
RS232_CTS_OUT => RS232_CTS_OUT,
RS232_RX_DATA => RS232_RX_DATA,
LED_0 => LED_0,
LED_1 => LED_1,
LED_2 => LED_2,
LED_3 => LED_3
);
-- No clocks detected in port list. Replace <clock> below with
-- appropriate port name
-- constant system_clock_period := 10ns;
--ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax
error near constant
--ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error
near ns ; expected type void
--ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92.
system_clock_period is not declared
system_clock_process :process
begin
system_clock <= '0';
--wait for system_clock_period/2;
wait for 10ns/2;
system_clock <= '1';
--wait for system_clock_period/2;
wait for 10ns/2;
end process;
-- Stimulus process
stim_proc: process
begin
-- hold reset state for 100ms.
wait for 100ns;
--wait for system_clock_period*10;
wait for 10ns*10;
-- insert stimulus here
wait;
end process;
END;
-----------------------------------------------
although I kept getting an error on this line:
constant system_clock_period := 10ns;
--ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax
error near constant
--ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error
near ns ; expected type void
--ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92.
system_clock_period is not declared
anybody know whats wrong with the syntax???
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