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
Hi everybody, When configuring my Virtex 5 with encrypted bitstream (CCLK rate is 100 MHz) the FPGA doesn't start up ! whereas it is not the case for unencrypted one . Why ??? I need to configure the FPGA as quickly as possible. Thanks.Article: 138326
On Feb 16, 12:16=A0pm, dajjou <swissiyous...@gmail.com> wrote: > Hi everybody, > > When configuring my Virtex 5 with encrypted bitstream (CCLK rate is > 100 MHz) the FPGA doesn't start up ! > whereas it is not the case for unencrypted one . Why ??? > I need to configure the FPGA as quickly as possible. > > Thanks. you need to use parallel mode :( i think the 100mhz ecnrypted mode may not be supported, please check the datasheets AnttiArticle: 138327
Hi all,
We are using the FRAME_ECC_VIRTEX4 primitive performing readback/
writeback with a PPC and HWICAP.
The primitive works as expected for "no error" or "multiple errors"
situations, but when a "single error" is detected the SYNDROME[10:0]
must be decoded.
According to the "Virtex-4 Configuration User Guide" the operation is
(where syndrome is the direct output of the primitive):
-----
signal bit_index : std_logic_vector(10 downto 0);
signal syndrome : std_logic_vector(10 downto 0);
bit_index(10 downto 5) <= syndrome(10 downto 5) - ("01011" & syndrome
(10));
bit_index(4 downto 0) <= syndrome(4 downto 0);
------
The bit_index value we are obtaining this way is not directly the
offset of the flipped bit.
Should the bit_index correspond to the 0-1311 position of the bit flip
in the frame data,
or any extra decoding procedure should be done?
Thanks,
Mikel A-a
Article: 138328
On Feb 15, 4:48 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 13 Feb 2009 12:24:36 -0800 (PST), jleslie48 wrote:
> >expanded to this now:
> > op_GOTOL & 02 & -- ok here is the new gotol, it will
> > -- jump to the label rather
> > -- than the array index, so the length
> > -- of the strings no longer
> > -- needs to be calculated
>
> Well done for making this work - I reckon it's a good
> "rite of passage" and you should be able to make progress
> with reasonable confidence now.
>
> However, I question the motivation. Wouldn't it have
> been way, way easier to write a little "compiler" to do
> all the necessary string length and address calculations
> in advance, generating a piece of VHDL code (or a Xilinx
> memory-format file) to graft into your project, so that
> you could stick with the nice simple "goto address"
> hardware? Scanning the program to find its labels
> must be a non-trivial overhead.
>
> >all is working, now, and I'm quite happy with this layout. I imagine
> >after every op_MESSAGE I will be placing a
> >op_WAIT_FOR_LABEL in the future. My UART mesages will all reside in
> >this packet, with the Top process changing a LABEL_TO_BE SENT byte and
> >zeroing it out on completion. In this way My entire array of canned
> >output messages can be called up on demand.
>
> Consider a redirection table, where the addresses of
> the various strings are stored in a simple lookup table
> indexed by label number.
>
> > then onto dynamic messaging (aka, type 5 values
> >into the RS232, and send the message, "the values are,
> >x1, x2, x3, x4, >x5 and the sum is yyy").
>
> I still don't understand the ideological barrier to using
> a soft-core CPU in the FPGA. However cunning your
> programmable functionality, you'll soon enough encounter
> a problem where it's not cunning enough, but real SOFTWARE
> would easily do what you need. The CPU doesn't need to be
> big or clever - but it *does* need to be a real computing
> engine, which is unlikely to be true of your string-indexing
> machine....
> Picoblaze is FREE, by almost any reasonable measure. Having
> such a soft-core on your FPGA doesn't call your manhood into
> question, nor does it inhibit your ability to do very fast
> stuff (far too fast for a CPU) elsewhere on the FPGA.
> --
> 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.
John, Antti,
At this stage, this is mostly an exercise in controlling mechanisms in
a
FPGA using VHDL. I'm sure its not the best and I'm sure in the future
I'll
be exploring more efficient ways of doing things, but for now, the
hammer and
chisel are what I need to learn.
"Consider a redirection table, where the addresses of
the various strings are stored in a simple lookup table
indexed by label number. "
That is exactly what I did, I think. Actually I had a question about
that.
I used your [JB's] function CONTENTS as a template and created
function FIND_LABEL:
---------------------------------------------------------------------
function find_label(pgm: t_ubyte_array) return t_lbl is
constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
variable it: t_lbl;
begin
it := (others => 0);
for i in 0 to (p'length-2) loop
if (p(i)= op_label) then
it(p(i+1)) := i;
end if;
end loop;
return it;
end;
-- The ROM contents, initialized from the generic
constant the_rom: t_rom := contents(the_program);
constant the_label: t_lbl := find_label(the_program);
...
when op_LABEL =>
PC <= PC+1; -- skip the label data lbl
gen_state <= new_PC;
when op_GOTO =>
PC <= rom_data;
gen_state <= new_PC;
when op_GOTOL =>
PC <= the_label(rom_data); --lbl
gen_state <= new_PC;
when op_HALT =>
---------------------------------------------------------------------
My question is, when (to use the term loosely) does this function
run (again using the term loosely) It seems to me that it only
"needs" to establish the arrays once, but I know the process is
alive always, is it constantly remaking the storage locations
the_rom and the_label over and over?
It probably doesn't make a difference, I'm thinking the conveyor-belt
linear system of cpu programming. In that case you don't want to keep
parsing the same string over and over, but in the FPGA world it
doesn't
make a difference.
"Wouldn't it have
been way, way easier to write a little "compiler" to do
all the necessary string length and address calculations
in advance, generating a piece of VHDL code (or a Xilinx
memory-format file) to graft into your project, so that
you could stick with the nice simple "goto address"
hardware? Scanning the program to find its labels
must be a non-trivial overhead. "
Again, I'm pretty sure that is what I did. I'm not
sure what you mean by nice simple "goto address"
to me the simplest way was to drop a marker at
the beginning of whatever message I want and
reference that marker with the GOTOL command.
In this way, all the string and address calcuations
ARE calculated as you suggested.
Sincerely,
Jon
Article: 138329
On Mon, 16 Feb 2009 05:21:37 -0800 (PST), jleslie48 wrote:
>At this stage, this is mostly an exercise in controlling
>mechanisms in a FPGA using VHDL.... the hammer and
>chisel are what I need to learn.
Fair enough. Good to try it on an example that has
reasonably interesting control flow, but where the
data manipulation is trivial.
>"Consider a redirection table, where the addresses of
>the various strings are stored in a simple lookup table
>indexed by label number. "
>
>That is exactly what I did, I think. Actually I had a question about
>that.
>I used your [JB's] function CONTENTS as a template and created
>function FIND_LABEL:
>
>---------------------------------------------------------------------
> function find_label(pgm: t_ubyte_array) return t_lbl is
> constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> variable it: t_lbl;
> begin
> it := (others => 0);
> for i in 0 to (p'length-2) loop
> if (p(i)= op_label) then
> it(p(i+1)) := i;
> end if;
> end loop;
> return it;
> end;
Very nice. Give the synth tool lots of work to do.
THAT is the payoff you get when software folk have
struggled to understand how this works - they can
easily see how to get some real mileage out of the
compiler. I wish more of the design community were
prepared to do the same :-)
> -- The ROM contents, initialized from the generic
> constant the_rom: t_rom := contents(the_program);
> constant the_label: t_lbl := find_label(the_program);
OK, you've used the function to initialize a constant
(at the architecture or process level) so it gets
executed at ELABORATION time - the COMPILER takes
the hit, the hardware just sees a lookup table (ROM).
You have written my "string address compiler" in VHDL!
Now to add some compiler error checks (duplicate
label definitions?) - consider using a VHDL assert
statement for that:
if (p(i)= op_label) then
assert it(p(i+1)) = 0 -- Nothing there yet, I hope
report "Duplicate label " & integer'image(p(i+1))
& " at address " & integer'image(i+1)
severity FAILURE;
it(p(i+1)) := i;
end if;
will cause synthesis to fail on that error.
By contrast, a constant declared in a function
or procedure is evaluated afresh every time the
subprogram is called, and therefore it typically
costs the HARDWARE some effort (unless the compiler
can see that it is truly invariant, and optimize
the function away).
>My question is, when (to use the term loosely) does this function
>run (again using the term loosely) It seems to me that it only
>"needs" to establish the arrays once, but I know the process is
>alive always, is it constantly remaking the storage locations
>the_rom and the_label over and over?
See above. When considering VHDL you need to be very clear
about the idea of ELABORATION - the last part of compilation,
very roughly analogous to linking in C. At elaboration time,
the instance hierarchy is constructed top-down. Constants
are given their values, and then possibly used to determine
the structure of child instances. Elaboration determines
the hardware's structure, but does not represent activity
within the hardware itself.
Processes, on the other hand, execute in response to
signal-change events and therefore represent real
hardware activity.
>It probably doesn't make a difference
It most certainly does! Remember that any piece of VHDL
that does not contain a "wait" statement must execute in
zero simulated time, and therefore must represent the
behaviour of a piece of combinational logic in hardware.
What nightmare hardware would be needed to determine the
set of label addresses as a boolean-logic function of the
input string? Aaaaargh!
> I'm thinking the conveyor-belt
>linear system of cpu programming. In that case you don't want to keep
>parsing the same string over and over, but in the FPGA world it
>doesn't make a difference.
Eh?????!!!!! See above....
>"Wouldn't it have
>been way, way easier to write a little "compiler" to do
>all the necessary string length and address calculations
>in advance, generating a piece of VHDL code (or a Xilinx
>memory-format file) to graft into your project, so that
>you could stick with the nice simple "goto address"
>hardware? Scanning the program to find its labels
>must be a non-trivial overhead. "
>
>Again, I'm pretty sure that is what I did. I'm not
>sure what you mean by nice simple "goto address"
>to me the simplest way was to drop a marker at
>the beginning of whatever message I want and
>reference that marker with the GOTOL command.
>In this way, all the string and address calcuations
>ARE calculated as you suggested.
More or less, but you still need to access your
indirection table once per jump, whereas you *could*
precalculate the jump addresses and avoid the table
lookup. Imagine this "program":
MSG "Hello"
GOTO LabelA
LABEL LabelB
MSG "At B"
HALT
LABEL LabelA
MSG "At A"
GOTO LabelB
Now, I could imagine compiling this into the "machine code"
address code
0 MSG
1 "Hello"
6 EOM
7 GOTO 16 // GOTO LabelA
9 MSG // LabelB is at address 9
10 "At B"
14 EOM
15 HALT
16 MSG // LabelA is at address 16
17 "At A"
21 EOM
22 GOTO 9 // GOTO LabelB
No label lookup table is now required, right?
All the "compilation" work was done by the synthesis
tool, at elaboration time, leaving the minimum of
run-time hardware activity and therefore saving
hardware and allowing for higher clock rates.
Maybe you've already done this and/or more, so please
ignore me if I'm telling you stuff you already know.
Enjoy
--
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: 138330On 15 f=E9v, 20:02, Giuseppe Marullo <giuseppe.maru...@nospaminame.com> wrote: > Great info, thanks. They have a User guide for the Logic Analyzer: > > http://oakmicros.com/content/downloads/View-document/Logic-Analyzer-U... > > Carsten, do you mind sharing any .sla and or .slp ? > > I would like to travel around the gui with something on the screen. > > In the meantime I tried to create the bitfile for my board (a Xylo-LM > with a Spartan3E-500) but got a bunch of errors. > > I have found the Digilent Spartan3 board, but it is the 400K version, so > I need to fix the problem with the WebISE, I need the correct bitfile > anyway. I hope that this board can be used as well. > > Giuseppe > > giuseppe.maru...@nospaminame.com Thanks Carsten for the info, these small boards look nice. Giuseppe, here are two files : http://heliscar.com/greg/A2C.slp and http://heliscar.com/greg/A2C.sla They do not contain much stuff into them, but they might be useful if you just want to test the GUI.Article: 138331
Hi all My goal was to transfer an Assembler implementation that was running on an ARM chip to the PowerPC 405 architecture on a Xilinx Virtex II Pro. In the meantime this is working but for some reason the PowerPC implementation is more than 10 times!!! slower than the ARM chip implementation. I can only think of 3 reasons: 1) In the ARM implementation I save 16 registers on the stack, whereas I save 32 registers when working with the PowerPC. mflr 0 // save register and set up the stack frame stw 0, 4(1) addi 1, 1, -124 stmw 3, 8(1) // do some stuff lmw 3, 8(1) // restore registers and destroy the stack frame addi 1, 1, 124 lwz 0, 4(1) mtlr 0 This is the way how I set up stack frames and destroyed them in routine calls. Shouldnt really have a bad impact on the performance? 2) The multiplier in the PowerPC architecture. The ARM multiplier has a latency of 5 instructions, but if I am not completly wrong also the multiplier in the PowerPC 405 has also a latency of 5 clock cycles so this should not be the issue? 3) Clock Frequency: I used the EDK BaseSystem Builder where the external clock is 24 MHz and I told the tool that I also wanna have the PowerPC running at this clock frequency. This seems to be the most likely source for the problem which I will have to check now. However, if anybody has an other idea why the PowerPC implementation is so slow I would be thankful for some hints. Thanks!Article: 138332
I am wondering how does John implement dual bank controller in Spartan-3A http://www.enterpoint.co.uk/oem_industrial/hollybush2.html the above includes the link to the S3A product with DDR3 memories what makes me wonder is that Xilinx says http://www.xilinx.com/prs_rls/2007/silicon_vir/0793_ddr3sdram.htm that Virtex-5 are the first FPGA's in production supporting DDR3 if enternpoint has proven DDR3 interface with DDR3 this should be big news? Like written bold on Xilinx first company to offer DDR3 support in low cost FPGA family? AnttiArticle: 138333
On Fri, 06 Feb 2009 17:43:21 +0000, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Fri, 06 Feb 2009 12:36:49 +0000, news@rblack01.plus.com wrote: > >>Say I have a register described by a clocked process: >> >>signal test_int : integer; >>signal event1 : std_logic; >>signal event2 : std_logic; >>signal event3 : std_logic; >> >>process(clk) begin >> if(clk'event and clk='1') then >> if(event1 = '1') then >> test_int <= 1; >> end if; >> if(event2 = '1') then >> test_int <= 2; >> end if; >> if(event3 = '1') then >> test_int <= 3; >> end if; >> end if; >>end process; >> >>If event1, event2 and event3 are all high when the clock edge occurs, >>is test_int guaranteed to be set to 3 due to this being the last >>assignment in the process? > >As Mike and Enes have already confirmed, the answer is "yes". > >Just to enlarge on this a little: When you make >a <= signal assignment in VHDL, you are scheduling - >planning - an update to the signal for some time in >the future. A simple assignment > > s <= e; > >evaluates expression "e" immediately, and then schedules >an assignment of that value on to signal "s" for a time >one delta cycle into the future. From an RTL/design >perspective, you can think of that delta cycle as being >"just after the clock edge". > > s <= e after 5 ns; > >evaluates "e" immediately, but schedules the update of >"s" for 5 ns into the future. Of course you can't >meaningfully do this for a synthesizable design, >because synthesis does not know how to make time delays >reliably, so it will be treated exactly the same as >the zero-delay assignment for synthesis (and you may >get a warning message). > >But what happens when you make more than one assignment >to the same signal, as in your example? The answer is >quite complicated to describe, but has simple and >intuitive effects: > >When you execute the signal assignment, it schedules an >update to the signal at some future time T, which can >be anything greater than or equal to (NOW + 1 delta). >This new scheduled update affects any existing scheduled >updates as follows: > >1) Any existing scheduled updates at times >= T are > cancelled. This is the behaviour that your code > depends on. >2) Working backwards from time T towards NOW, VHDL > inspects each scheduled update to "s". If it is > to EXACTLY THE SAME VALUE as your new update, > the existing earlier scheduled update is preserved. > But as soon as VHDL encounters an update to a > different value, it cancels that and all earlier > updates. > >The second behaviour has the interesting effect that >repeated attempts to bring a signal to a certain value >after a time delay will indeed succeed. Consider this: > > for i in 1 to 10 loop > s <= K after 10 ns; -- K is the same every time. > wait for 5 ns; > end loop; > >Suppose you start this loop at time 0; when will "s" >change its value to K? Answer: at time 10 ns. The >second assignment, executed at time 5 ns and scheduled >for 15 ns, does NOT cancel the 10 ns schedule because >it's to the same value. > >If you don't want a new assignment to affect existing >already-scheduled updates, you can use transport delay: > > s <= transport e after 10 ns; > >This form of assignment creates the new schedule without >affecting previous scheduled assignments; in other words, >it obeys my rule (1) but it ignores rule (2). > >Of course, most of this stuff makes sense only for >simulation, not for synthesis. But it justifies >doing multiple assignments to the same signal within >a synthesizable process; it is completely certain >that only the last-executed assignment will take effect. OK, thanks, very detailed explanation! This behaviour is what I was hoping for. The real code I am working on has a much more complicated if-else structure inside the process, I try to keep all operations that modify a register inside the same clocked process. So if several different events can modify the register, I can force a particular priority on them - the last assignment in the process has highest priority.Article: 138334
> Giuseppe, here are two files : http://heliscar.com/greg/A2C.slp and Thanks, it is a nice gui, still fighting with the VHDL to see if the 400k board could be used, so far no dice. Is there any good soul that could try to build a bitfile for the 400k version of the Digilent board? These are the two source files: Original http://www.sump.org/projects/analyzer/downloads/la-src-0.8.tar.bz2 OAK "modified" ones: http://oakmicros.com/content/downloads/Download-document/Logic-Analyzer-Files.html I got different errors, I just change the FPGA model but it seems it is not enough. I tried with 10.1 ISE Webpack. TIA, GiuseppeArticle: 138335
On Feb 16, 9:36 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Mon, 16 Feb 2009 05:21:37 -0800 (PST), jleslie48 wrote:
> >At this stage, this is mostly an exercise in controlling
> >mechanisms in a FPGA using VHDL.... the hammer and
> >chisel are what I need to learn.
>
> Fair enough. Good to try it on an example that has
> reasonably interesting control flow, but where the
> data manipulation is trivial.
>
>
>
> >"Consider a redirection table, where the addresses of
> >the various strings are stored in a simple lookup table
> >indexed by label number. "
>
> >That is exactly what I did, I think. Actually I had a question about
> >that.
> >I used your [JB's] function CONTENTS as a template and created
> >function FIND_LABEL:
>
> >---------------------------------------------------------------------
> > function find_label(pgm: t_ubyte_array) return t_lbl is
> > constant p: t_ubyte_array (0 to pgm'length-1) := pgm;
> > variable it: t_lbl;
> > begin
> > it := (others => 0);
> > for i in 0 to (p'length-2) loop
> > if (p(i)= op_label) then
> > it(p(i+1)) := i;
> > end if;
> > end loop;
> > return it;
> > end;
>
> Very nice. Give the synth tool lots of work to do.
> THAT is the payoff you get when software folk have
> struggled to understand how this works - they can
> easily see how to get some real mileage out of the
> compiler. I wish more of the design community were
> prepared to do the same :-)
>
> > -- The ROM contents, initialized from the generic
> > constant the_rom: t_rom := contents(the_program);
> > constant the_label: t_lbl := find_label(the_program);
>
> OK, you've used the function to initialize a constant
> (at the architecture or process level) so it gets
> executed at ELABORATION time - the COMPILER takes
> the hit, the hardware just sees a lookup table (ROM).
> You have written my "string address compiler" in VHDL!
> Now to add some compiler error checks (duplicate
> label definitions?) - consider using a VHDL assert
> statement for that:
>
> if (p(i)= op_label) then
> assert it(p(i+1)) = 0 -- Nothing there yet, I hope
> report "Duplicate label " & integer'image(p(i+1))
> & " at address " & integer'image(i+1)
> severity FAILURE;
> it(p(i+1)) := i;
> end if;
>
> will cause synthesis to fail on that error.
>
> By contrast, a constant declared in a function
> or procedure is evaluated afresh every time the
> subprogram is called, and therefore it typically
> costs the HARDWARE some effort (unless the compiler
> can see that it is truly invariant, and optimize
> the function away).
>
> >My question is, when (to use the term loosely) does this function
> >run (again using the term loosely) It seems to me that it only
> >"needs" to establish the arrays once, but I know the process is
> >alive always, is it constantly remaking the storage locations
> >the_rom and the_label over and over?
>
> See above. When considering VHDL you need to be very clear
> about the idea of ELABORATION - the last part of compilation,
> very roughly analogous to linking in C. At elaboration time,
> the instance hierarchy is constructed top-down. Constants
> are given their values, and then possibly used to determine
> the structure of child instances. Elaboration determines
> the hardware's structure, but does not represent activity
> within the hardware itself.
>
> Processes, on the other hand, execute in response to
> signal-change events and therefore represent real
> hardware activity.
>
> >It probably doesn't make a difference
>
> It most certainly does! Remember that any piece of VHDL
> that does not contain a "wait" statement must execute in
> zero simulated time, and therefore must represent the
> behaviour of a piece of combinational logic in hardware.
>
> What nightmare hardware would be needed to determine the
> set of label addresses as a boolean-logic function of the
> input string? Aaaaargh!
>
> > I'm thinking the conveyor-belt
> >linear system of cpu programming. In that case you don't want to keep
> >parsing the same string over and over, but in the FPGA world it
> >doesn't make a difference.
>
> Eh?????!!!!! See above....
>
>
>
> >"Wouldn't it have
> >been way, way easier to write a little "compiler" to do
> >all the necessary string length and address calculations
> >in advance, generating a piece of VHDL code (or a Xilinx
> >memory-format file) to graft into your project, so that
> >you could stick with the nice simple "goto address"
> >hardware? Scanning the program to find its labels
> >must be a non-trivial overhead. "
>
> >Again, I'm pretty sure that is what I did. I'm not
> >sure what you mean by nice simple "goto address"
> >to me the simplest way was to drop a marker at
> >the beginning of whatever message I want and
> >reference that marker with the GOTOL command.
> >In this way, all the string and address calcuations
> >ARE calculated as you suggested.
>
> More or less, but you still need to access your
> indirection table once per jump, whereas you *could*
> precalculate the jump addresses and avoid the table
> lookup. Imagine this "program":
>
> MSG "Hello"
> GOTO LabelA
> LABEL LabelB
> MSG "At B"
> HALT
> LABEL LabelA
> MSG "At A"
> GOTO LabelB
>
> Now, I could imagine compiling this into the "machine code"
>
> address code
> 0 MSG
> 1 "Hello"
> 6 EOM
> 7 GOTO 16 // GOTO LabelA
> 9 MSG // LabelB is at address 9
> 10 "At B"
> 14 EOM
> 15 HALT
> 16 MSG // LabelA is at address 16
> 17 "At A"
> 21 EOM
> 22 GOTO 9 // GOTO LabelB
>
> No label lookup table is now required, right?
> All the "compilation" work was done by the synthesis
> tool, at elaboration time, leaving the minimum of
> run-time hardware activity and therefore saving
> hardware and allowing for higher clock rates.
>
> Maybe you've already done this and/or more, so please
> ignore me if I'm telling you stuff you already know.
>
> Enjoy
> --
> 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.
Yes, these are the ideas I've been formulating all weekend long.
we are [finally] moving to the same page.
"Now to add some compiler error checks (duplicate
label definitions?) - consider using a VHDL assert "
Most definitely. My code is far from bullet-proof. My first
self-inflicted wound was this:
-- A LABEL is a marker, a noop, but used for the GOTOL lbl
constant op_LABEL : t_ubyte := 76; -- 'L'
and since my label parser was stupid, ANY 'L' character, including
the ones as part of the data of an op_MESSAGE generated label
lookups, and as the character after a 'L' character did not
necessarily
fit into the boundaries of my lookup table, this crashed big time.
Now the correct course of action would be to actually define a grammar
for the "the_program" command set, with context specifiers and full
language specfications. for example:
the_program ==> <set_of_comands>
<set_of_commands> ==> [<simple_command> [simple_command_tail]]
<simple_command_tail> ==> [& <simple_command>]
<simple_command> ==> [ op_HALT |
op_DELAY <op_delay_data> |
...
etc.
however, I just took a tactical approach; made sure that my op_LABEL
tag was in a disjoint set from any possible data value. Simply put, I
made
sure that the op_LABEL command would never be in any part of the
program in another context by changing the constant to:
-- A LABEL is a marker, a noop, but used for the GOTOL lbl
constant op_LABEL : t_ubyte := 176; --NON standard ascii char.
the value 176 ~should~ never be in an ascii string in the_program. Now
if an application programmer should want a delay of of 176 units, well
then
I'm gonna slap him about the head and neck...
Of course this is a cheat, but it will work with just being a little
careful.
"Imagine this "program":
MSG "Hello"
GOTO LabelA
LABEL LabelB
MSG "At B"
HALT
LABEL LabelA
MSG "At A"
GOTO LabelB "
Not exactly what I had imagined, I had imagined it this way:
LABEL xx1:
MSG "the quick brown fox"
WGOTOL <noop>
LABEL xx2:
MSG "Mary had a little lamb"
WGOTOL <noop>
...
LABEL xxn:
MSG "Its the end of the world as we know it."
WGOTOL <noop>
where WGOTOL is similar to your
op_WAIT_FOR_CHAR
only instead of getting its data fields from the next byte
and the rx_data line, the entity would have a new "input" of the
print_target_label, which would have the value of
xx1, xx2, ... xxn
and thus send the MSG out the uart and then spin waiting for the
next update to print_target_label.
Should have that done shortly.
Sincerely,
Jon
sincerely,
Jon
Article: 138336On Mon, 16 Feb 2009 08:51:55 -0800 (PST), jleslie48 wrote: > and since my label parser was stupid, ANY 'L' character, > including the ones as part of the data of an op_MESSAGE > generated label lookups Tee hee. Betcha you would never have done anything so dumb when working on your home territory :-) Be aware that the Xilinx blockRAMs natively have 9-bit data width. So you could rather easily use the MSB as an "opcode" or other out-of-band marker, simplifying this sort of stuff no end, and still preserve 8 data bits in the message literals. -- 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: 138337
On Feb 16, 4:27=A0am, colin <colin_toog...@yahoo.com> wrote: > Hi everyone. > > I've been designing for spartan3 for the last few years but I'm just > starting on a virtex 5 project. > > I am surprised at the incredible lack of decoupling XILINX now > recomend. Does anyone has experience of following the XILINX > recomendations? I accept that the FPGA will work fine but I'm > wondering at the amount of noise injected back into the PCB. The FPGA > is a logic engine to a processor sitting right alongside it whose > engineers don't yet understand SI or PDS at all with no GND pins near > the power pins. > > Any thoughts appreciated. > > Colin The reason for the reduced decoupling for packages larger than 324 balls, is that they have added high-speed decoupling caps into the BGA package itself. Theoretically this should give you less noise injected into the PCB than placing the highspeed bypass on the board. Maybe your Xilinx FAE can give you more details on the size and number of caps in your package. Regards, GaborArticle: 138338
On Feb 16, 5:37=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > On Feb 16, 12:16=A0pm, dajjou <swissiyous...@gmail.com> wrote: > > > Hi everybody, > > > When configuring my Virtex 5 with encrypted bitstream (CCLK rate is > > 100 MHz) the FPGA doesn't start up ! > > whereas it is not the case for unencrypted one . Why ??? > > I need to configure the FPGA as quickly as possible. > > > Thanks. > > you need to use parallel mode :( > i think the 100mhz ecnrypted mode may not be supported, please > check the datasheets > > Antti I've run into other problems at 100 MHz for unencrypted bitstreams as well. When the DONE signal is allowed to float high, the startup state logic can sample it in the threshold region (yes the chip samples the pin unless you set "Internal Done Pipe") and lock up. I solved this using the internal done pipe, but another recommendation was to "Drive Done High". My external DONE pullup was 330 ohms as recommended, but at 100 MHz, this is not fast enough. Another approach to fix this might be to slow down CCLK at or near the end of the bitstream. Regards, GaborArticle: 138339
Hello Antti, on the webpage is a .ucf file available, but this contains NOT the DDR3-SDRAM pins. You are right, spartan-3A DSP does not support DDR3-Voltage Levels. Use the SSTL18_[I,II] at VCCO=1.5V and Vref=0,75V should be possible, but nobody guarantees the IO-Timing and Voltage Levels. But there is a second challenge. The maximal clock cycle with DDR3- SDRAM DLL enabled is 3.3 ns (~300 Mhz) this should be above any the Spartan-3A Memory-Controllers. Micron Datasheet: http://download.micron.com/pdf/datasheets/dram/ddr3/1Gb%20DDR3%20SDRAM.pdf This DLL can disabled, but the relationchip between clk and data output delay is lost. Second you must disable the ODT (On Die Termination). In my opinion, the SDRAM-Controller is the big challenge. So we wait for a DDR3-Controller from enterpoint. Daniel On 16 Feb., 16:54, Antti <Antti.Luk...@googlemail.com> wrote: > I am wondering how does John implement dual bank controller in > Spartan-3A > > http://www.enterpoint.co.uk/oem_industrial/hollybush2.html > > the above includes the link to the S3A product with DDR3 memories > > what makes me wonder is that Xilinx says > > http://www.xilinx.com/prs_rls/2007/silicon_vir/0793_ddr3sdram.htm > > that Virtex-5 are the first FPGA's in production supporting DDR3 > > if enternpoint has proven DDR3 interface with DDR3 this should > be big news? Like written bold on Xilinx > > first company to offer DDR3 support in low cost FPGA family? > > AnttiArticle: 138340
"Type of temp_label_index is incompatible with type of lbl_data."
I've been futzing with this for an hour now what's the answer???
; lbl_data : in std_logic_vector(7 downto 0)
subtype t_lbl_r is integer range 0 to 15; -- 16 labels are
availabe for now.
signal temp_label_index : t_lbl_r;
if (lbl_data /= x"00") then
temp_label_index <= lbl_data(3 downto 0); ----<<< error here
PC <= the_label(temp_label_index); --lbl
this also doesn't work:
"The expression can not be converted to type integer."
temp_label_index <= integer(unsigned(lbl_data(3 downto 0)));
Article: 138341> > Thanks, it is a nice gui, still fighting with the VHDL to see if the > 400k board could be used, so far no dice. > I already responded privately to Giuseppe. The fix is to simply delete the la_guide.ncd file (which seems to be a cached output file) and rebuild the map file. Note that the only differences in the Oak Micros version of the download package are: 1. A fix to the la.ucf file that fixes an error message from 10.1 ISE Webpack 2. A "compiled" version of a 10.1 ISE project 3. Added the configuration files needed for downloading the logic analyzer into FPGA development board. I provided this to make it easier for newbies to get started. I'm also investigating (with someone else) some updates to improve the GUI. We are starting from the source both on http://www.sump.org/projects/analyzer/ and the SourceForge project: https://sourceforge.net/projects/jlac/ See my User Guide: http://oakmicros.com/content/downloads/View-document/Logic-Analyzer-User-Guide.html See my interface board: http://oakmicros.com/content/omla32-Logic-Analyzer-Interface-Card.html Mike Perks oakmicros.comArticle: 138342
On Mon, 16 Feb 2009 12:24:42 -0800 (PST), jleslie48 wrote: >"Type of temp_label_index is incompatible with type of lbl_data." Wrong-group alarm: take VHDL language questions to comp.lang.vhdl. >I've been futzing with this for an hour now what's the answer??? (1) Get a Doulos Golden Reference Guide, or something like it; (2) Trawl comp.lang.vhdl for references to "numeric_std"; (3) Be aware that VHDL is a (very) strongly typed language. > ; lbl_data : in std_logic_vector(7 downto 0) std_logic_vector is just a bag-o-bits with no numeric meaning. > subtype t_lbl_r is integer range 0 to 15; > signal temp_label_index : t_lbl_r; That's a numeric value that has no bag-o-bits meaning (although you, I and a synthesis tool all think it has). >if (lbl_data /= x"00") then That's OK, literal comparison of one bag-o-bits with another. > temp_label_index <= lbl_data(3 downto 0); ----<<< error here Of course it's an error; they have totally different data types. Blast these hooligan C programmers; their wretched BCPL-inspired bit-picking will be the death of us. >this also doesn't work: >"The expression can not be converted to type integer." Ahah. Long may the angels continue to dance on the pinhead. Confuse at your peril "type conversion" and "type conversion function" (details below). >temp_label_index <= integer(unsigned(lbl_data(3 downto 0))); So... unsigned is a type that has the same footprint (array of std_logic indexed by natural) as std_logic_vector, therefore it is "closely related" and it's ok to say unsigned(some_std_logic_vector_value) and you get the exact same bag-o-bits but now it has unsigned type. And unsigned type HAS a numeric meaning. But integer and unsigned are NOT closely related, so you need a TYPE CONVERSION FUNCTION to convert one to another: temp_label_index <= to_integer(unsigned(lbl_data(3 downto 0))); (spot the three additional characters in "to_integer"). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See the well-informed discussion on the very recent thread unsigned(), unsigned'(), to_unsigned() on comp.lang.vhdl; and many other such over the past few years. -- 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: 138343
On Feb 16, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Mon, 16 Feb 2009 12:24:42 -0800 (PST), jleslie48 wrote: > >"Type of temp_label_index is incompatible with type of lbl_data." > > Wrong-group alarm: take VHDL language questions to comp.lang.vhdl. > > >I've been futzing with this for an hour now what's the answer??? > > (1) Get a Doulos Golden Reference Guide, or something like it; > (2) Trawl comp.lang.vhdl for references to "numeric_std"; > (3) Be aware that VHDL is a (very) strongly typed language. > > > ; lbl_data : in std_logic_vector(7 downto 0) > > std_logic_vector is just a bag-o-bits with no numeric meaning. > > > subtype t_lbl_r is integer range 0 to 15; > > signal temp_label_index : t_lbl_r; > > That's a numeric value that has no bag-o-bits meaning > (although you, I and a synthesis tool all think it has). > > >if (lbl_data /= x"00") then > > That's OK, literal comparison of one bag-o-bits with another. > > > temp_label_index <= lbl_data(3 downto 0); ----<<< error here > > Of course it's an error; they have totally different > data types. Blast these hooligan C programmers; their > wretched BCPL-inspired bit-picking will be the death of us. > > >this also doesn't work: > >"The expression can not be converted to type integer." > > Ahah. Long may the angels continue to dance on the > pinhead. Confuse at your peril "type conversion" and > "type conversion function" (details below). > > >temp_label_index <= integer(unsigned(lbl_data(3 downto 0))); > > So... unsigned is a type that has the same footprint > (array of std_logic indexed by natural) as std_logic_vector, > therefore it is "closely related" and it's ok to say > unsigned(some_std_logic_vector_value) > and you get the exact same bag-o-bits but now it has > unsigned type. And unsigned type HAS a numeric meaning. > But integer and unsigned are NOT closely related, so you > need a TYPE CONVERSION FUNCTION to convert one to another: > > temp_label_index <= to_integer(unsigned(lbl_data(3 downto 0))); > > (spot the three additional characters in "to_integer"). > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > See the well-informed discussion on the very recent thread > unsigned(), unsigned'(), to_unsigned() > on comp.lang.vhdl; and many other such over the > past few years. > -- > 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. Ratta fracken, muda, friggen.... (he says under his breath) 10 points for Gryffindor... works.Article: 138344
On Feb 16, 9:49=A0pm, melvin <melvinv...@gmail.com> wrote: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Currently i am doing my final year= =A0project on > xilinx cpld 9572 > > =A0 =A0 How do we can access registers in this cpld using vhdl ....... Search for some simple examples (which may not be 9572 specific), and re-target the device to 9572 (or other family members). Then, look at the tool-flow fitter report files, to see what resource was used, and you will learn how the code maps to macrocells. -jgArticle: 138345
On Feb 16, 3:49=A0am, melvin <melvinv...@gmail.com> wrote: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Currently i am doing my final year= =A0project on > xilinx cpld 9572 > > =A0 =A0 How do we can access registers in this cpld using vhdl ....... A XC9572 has 72 macro cells (MC), and each MC has a flip-flop. Flip- flops are used in counters, registers, and state machines. This type of info should be in your text books! After you -synthesize- your design, you can use ISE's RTL viewer to see a logic diagram of the results. If you need examples, ISE has them: Edit/language templates/VHDL/Synthesis Constructs/Coding Examples But please, use "rising_edge(clock)" instead of "<clock>'event and <clock>=3D'1'". It's "better", and it's less typing ;) HTH -Dave PollumArticle: 138346
On Feb 16, 11:28=A0am, n...@rblack01.plus.com wrote: > On Fri, 06 Feb 2009 17:43:21 +0000, Jonathan Bromley > <jonathan.brom...@MYCOMPANY.com> wrote: > >On Fri, 06 Feb 2009 12:36:49 +0000, n...@rblack01.plus.com wrote: > > >>Say I have a register described by a clocked process: > > >>signal test_int : integer; > >>signal event1 : std_logic; > >>signal event2 : std_logic; > >>signal event3 : std_logic; > > >>process(clk) begin > >> =A0 =A0 =A0 =A0if(clk'event and clk=3D'1') then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if(event1 =3D '1') then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0test_int <=3D 1; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if(event2 =3D '1') then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0test_int <=3D 2; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if(event3 =3D '1') then > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0test_int <=3D 3; > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if; > >> =A0 =A0 =A0 =A0end if; > >>end process; > > > OK, thanks, very detailed explanation! =A0This behaviour is what I was > hoping for. > The real code I am working on has a much more complicated if-else > structure inside the process, I try to keep all operations that modify > a register inside the same clocked process. =A0So if several different > events can modify the register, I can force a particular priority on > them - the last assignment in the process has highest priority. I'm curious, why would you use a construct that you need to ask help on when you could easily use a nested IF ELSIF structure and make it perfectly clear what is intended to yourself as well as any other designers who need to maintain your code. Don't get me wrong, I'm not saying the above is a bad way to code. But obviously it is a little less clear. For example, even if you understand the VHDL rules governing this, it is not clear to someone else if it is *possible* for event1, event2 and event3 to be active at the same time. So if someone else has to change the code, they don't know if you are counting on the priority of the events or if it does not matter. If you use IF ELSIF ELSEIF THEN, you will be clearly indicating that you inend to enforce a priority on the assignments. Not only that, it is fewer lines of code so it will be easier to debug... ;^) Just a thought. RickArticle: 138347
On Feb 16, 3:43=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > > See the well-informed discussion on the very recent thread > =A0 unsigned(), unsigned'(), to_unsigned() > on comp.lang.vhdl; and many other such over the > past few years. Jon, The problem you are seeing is due to the strong typing of VHDL and is intended to prevent you from shooting yourself in the foot. The above is, in a nutshell, what you need to learn to deal with this. After you fight... I mean *learn* the rules associated with this I'll let you tell me if it is worth it. I think if I had learned Verilog first, I would have never used VHDL. But I am pretty used to it now so no big deal. Still, there are millions of lines of code running the Internet or even satellites that have never been "protected" by strong typing. I think there are any number of other things that are much more important to correct design than strong typing. RickArticle: 138348
Hi Mike, thanks for your email, now I have a bitfile for the 400k, deleting the file worked but I have a failing timing constraint (that disappear with the xc3s200): Timing constraint: TS clock1 = PERIOD TI?MEGRP "clock1" TS xtalClock / 2 HIGH 50%; Could I safely ignore it? Sorry to bug all with this, but I can only get the 400k version, and I would buy it specifically to use it as a logic analyzer. Giuseppe mikep@oakmicros.com wrote: >> Thanks, it is a nice gui, still fighting with the VHDL to see if the >> 400k board could be used, so far no dice. >> > I already responded privately to Giuseppe. The fix is to simply delete > the la_guide.ncd file (which seems to be a cached output file) and > rebuild the map file. > > Note that the only differences in the Oak Micros version of the > download package are: > 1. A fix to the la.ucf file that fixes an error message from 10.1 ISE > Webpack > 2. A "compiled" version of a 10.1 ISE project > 3. Added the configuration files needed for downloading the logic > analyzer into FPGA development board. I provided this to make it > easier for newbies to get started. > > I'm also investigating (with someone else) some updates to improve the > GUI. We are starting from the source both on http://www.sump.org/projects/analyzer/ > and the SourceForge project: https://sourceforge.net/projects/jlac/ > > See my User Guide: http://oakmicros.com/content/downloads/View-document/Logic-Analyzer-User-Guide.html > See my interface board: http://oakmicros.com/content/omla32-Logic-Analyzer-Interface-Card.html > > Mike Perks > oakmicros.comArticle: 138349
rickman wrote: (snip) > I think if I had learned Verilog first, I would have never used VHDL. > But I am pretty used to it now so no big deal. Still, there are > millions of lines of code running the Internet or even satellites that > have never been "protected" by strong typing. I think there are any > number of other things that are much more important to correct design > than strong typing. I learned Verilog first. I can now usually read VHDL, but I don't claim to be able to write it. It does seem so wordy to me. -- glen
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