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
I second the suggestion to use Wishbone or slightly simplified variant thereof.Article: 138076
> On Feb 4, 11:09 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > >>> Enes Erdin <eneser...@gmail.com> wrote: >>> >>>> Long time passed since the last post but I wonder your opinions >>>> about this subject for today's technology. I am using a core2duo >>>> 1.8 GHz PC and for my design P&R takes 40 + minutes and want to buy >>>> a new PC powered by an AMD processor becasue of tis price but I can >>>> think some other configuration if it is worth, related to your >>>> opinions about : >>>> >>>> - dual core, quad core comparison >>>> - cache for the processor camparison >>> I have a triple core phenom, which I bought because of the low >>> price. They don't only come on powers of two. >>> >> Yes they do, AMD's triple cores are four cores with one turned off. >> This was required to increase yields to a profitable point. >> > Do you know this for a fact? When it comes to PCs I have read a lot > of rumor that gets repeated so much that it becomes "fact". Did AMD > say this or someone actually open the package to see the die or some > other way of verifying that it is the same silicon? I ask because > when the tricore part was about ready for release I read that it was a > new chip layout. Essentially they were shooting for a sweet spot > where they got more performance than a dual core, but lower price than > a quad core. Not that there is anything wrong with a "binned" part. > > Rick > Here's a Wired article were AMD execs talk about the (then) new processor. http://www.wired.com/techbiz/it/news/2007/09/tricore Here's the important snippet: "In terms of architecture, Brewer also confirmed on Monday that the yet-to-be named processor will basically be a quad-core processor with one core disabled, and that it will feature the company's Direct Connect architecture, as well as a shared L3 cache, and other architectural selling points that Intel currently lacks." ---Matthew HicksArticle: 138077
On Feb 4, 7:42 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> OK, I looked pretty hard at your code, and I am
> somewhat stumped. There is so much that is just
> so far away from what I would do - not the
> line-by-line minutiae of coding, but the overall
> approach. Two really big things that make it
> close to impossible to debug in a reasonable time:
>
> (1) You have several distinct processes, each
> taking responsibility for a block of activity.
> Consequently they have to hand-off from one to
> another in complicated ways. Very hard to
> manage correctly. It is far easier to have
> one process take responsibility for any single
> thread of activity.
>
> (2)You've just GOT to learn about state machines.
> Using some unholy boolean mess of flags to decide
> what to do on each clock is a recipe for disaster.
>
> So....... you'll probably be cross about this, or
> simply ignore it, but.... I've written a data
> generator to create your message strings. It's
> very incomplete so far, but it stores its information
> in a Xilinx blockRAM configured as ROM, and allows
> you to freely intermix messages and time delays.
> It could easily be extended to allow loopback
> tests, repeating messages and suchlike. Here's
> how you instantiate it to create two "hello world"
> messages:
>
> JSEB_DATA_GENERATOR: entity work.data_gen
> generic map
> ( PC_bits => 9 -- Width of ROM address
> , the_program =>
> -- Long startup delay
> op_DELAY & 200 &
> -- Send the first message
> op_MESSAGE & tua("Hello World") & EOM &
> -- short delay
> op_DELAY & 20 &
> -- send the second message
> op_MESSAGE & tua("Goodbye") & EOM &
> -- Freeze up so we do nothing more
> op_HALT
> )
> port map (.....)
>
> Nice, yes? op_DELAY, op_MESSAGE, op_HALT and EOM are
> single-byte constants.
>
> And I've rewritten the top module to use this alongside
> your existing UART transmitter. You should be able to
> try it out rather easily and tell me whether it works -
> I've only tried it in simulation so far, but I'll try
> it on my little demo board tomorrow.
>
> The sources are at
> http://www.oxfordbromley.plus.com/files/loki/
> and I hope the comments are sufficiently useful.
>
> cheers
> --
> 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.
"So....... you'll probably be cross about this, or
simply ignore it, but.... I've written a data
generator to create your message strings. "
Hardly. I am extremely appreciative of this effort.
I've been stuck in meetings all morning and had
not a chance to review, but I'm very interested
in an alternate model.
Thanks again,
Jon
Article: 138078On Thu, 05 Feb 2009 00:42:41 +0000, Jonathan Bromley wrote: > I've written a data >generator to create your message strings [...] >And I've rewritten the top module to use this alongside >your existing UART transmitter. You should be able to >try it out rather easily and tell me whether it works - >I've only tried it in simulation so far, but I'll try >it on my little demo board tomorrow. Yup, it worked just fine. Luckily I remembered to correct the baud rate divider to account for the 50MHz clock on my dev board, so I actually got it to work first time. Ah, the joys of simulation. Sincere apologies to all you seasoned engineers on comp.arch.fpga for my self-satisfaction here. I don't do so much with real hardware these days, so it's always nice to discover that I haven't completely lost my touch :-) Three noteworthy points: 1) My design appears to spit out one character of garbage at startup. This isn't real; it's caused by my PC's UART receiver seeing breaks or other junk as a result of the Tx line thrashing about while the FPGA is configured. As Antti and I pointed out, you need to leave plenty of settling time on the serial line after all the indeterminate stuff that happens at power-up and configuration. Depending on exactly how the RS-232 hardware is wired up on your platform, you may be able to engineer your way around this by ensuring that the line floats to its idle, marking state during configuration. On my cheap board, the Tx line goes to a space condition (=break) during configuration; I can't fix that unless I hack the board. 2) I note that you run all your UART and data logic from a 16.67MHz clock that you get by dividing your 100MHz system clock by 6. Have you checked that the divided clock is correctly using the clock distribution network? I'd be amazed if not, but if for any reason that has gone wrong, you could get some pretty strange behaviour. 3) I used the UART's TX_BUFFER_HALF_FULL signal to stall my data generator. I did that because your strange "15 works, 16 doesn't" symptoms suggested that the 16-deep FIFO might not be working quite right. To test this I switched over to using TX_BUFFER_FULL to throttle the data generator, and everything still works just fine. So the FIFO in Ken Chapman's UART design is blameless (no surprise there). -- 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: 138079
On Jan 25, 11:51=A0pm, ales.gor...@gmail.com wrote:
> Hi All,
>
> We are developing a custom borad with Spartan 3A DSP 1800 (FG676) and
> dual x16 DDR2 SDRAMs. Address lines shoud be separated for dual memory
> controller.
> Does anybody know how to create UCF constraints for dual memory
> controller in MIG 2.3? Dual memory controllers are only supported for
> Virtex 4&5.
>
> Cheers,
>
> Ales
as the S-6 feature list shows, the first spartan where xilinx will
support dual bank memory controllers is Spartan-6
sure it would be in theory doable for S-3A too, but then Xilinx would
say on any support request:
not supported, please use S-6
what makes me more uneasy about the dual DDR2 in S3A is following line
from the S3ASK starterkit UCF file
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# DIRT string to guaranty timing for the feedback path
NET "DDR2_CLK_FB_IBUFG"
ROUTE=3D"{3;1;3s700afg484;99142c6b!-1;-70632;33392;S!0;-159;0!1;-1688;"
"-10424!2;17836;-1100!3;-7468;-19156!4;1624;736!5;559;0;L!}";
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Xilinx can make the DDR2 memory to work, but it use
DIRT strings to make it pass timing.
this may become trickier with the dual banks, and well just the PCB
and
timing constraints are gonna be very sensitive for the dual DDR2 to
really
work reliable.
sure with little bit of luck all works as designed first try :)
but there is no guarantee... and definetly no support from Xilinx in
this regard
Antti
Article: 138080I am using spartan-II board..and in my project, i need number of signals of different frequencies..So i want to divide 50Mz clock of Spartan-II board to get the clocks of required frequencies...... So anyone suggest me on How to divide the clock frequency??......... any help will be greatly appreciated.............................Article: 138081
On Feb 5, 2:19 am, rickman <gnu...@gmail.com> wrote:
> On Feb 4, 4:28 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
>
>
> > Hey rick,
>
> > let me bring you up to date.
>
> > On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote:
> > ~ Given that, I can't see anything in your simulation capture that
> > shows
> > ~ anything wrong. It appears that sending data to the TX FIFO is
> > ~ working. The data sequence seems to be F23456789A123456 which is 16
> > ~ chars, filling the FIFO as shown by the tx_buffer_full flag going
> > ~ high. After the first char is written to the FIFO I see an enable
> > ~ pulse on uart_en_16_x_baud and one clock later I see the
> > rs232_tx_data
> > ~ go low. This all seems to be working as expected. I assume the
> > baud
> > ~ enable is 16x the actual bit rate, so the simulation time is not
> > long
> > ~ enough to watch the actual data emerge. Have you checked this to
> > see
> > ~ that the simulation is transmitting the data correctly? If the data
> > ~ is being received by the FPGA UART, are all 16 chars received
> > ~ correctly?
>
> > That's my big issue, The simulation, seems to show everything is
> > fine,
> > but when I download the code to the board, hook up the UART to my
> > PC terminal session, I get 23456789a123456f, (the F is last rather
> > than
> > first) but the simulation as you noticed as well look perfectly fine:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > also through testing I know this to be true:
>
> > I make the message string:
> > constant project_name_stg : string := "123456789a12345";
>
> > aka, 15 characters, all is well, I get on my pc terminal:
> > 123456789a12345
>
> > I make it 16 characters:
> > constant project_name_stg : string := "f23456789a123456";
>
> > my output becomes:
> > 23456789a123456f
>
> I think Jonathan or someone else suggested that if the F that should
> be the first character is showing up as the last character, this is
> *clearly not* an issue of startup delay. Something is wrong either
> with the way you are writing into the FIFO or perhaps the FIFO code
> itself is not correct. What may well be happening is that the first
> character written into the FIFO is being skipped by the UART. When
> you write exactly 16 characters somehow the UART output counter is
> getting messed up and skips to the second character. Of course this
> is speculation, but the fact that the 15 char message works ok shows
> it is not a startup issue. The 17 char message confuses me though.
> It skips the first char and only outputs 16 chars. Is there an output
> from the UART that acknowledges the strobe when you write to the tx
> fifo (other than the full flag)? If not, then the strobe should be
> accepted at any time. If there is a handshake flag, this needs to be
> checked before writing to the FIFO again that that might explain the
> mixup on 16 or more chars. One last comment on the FIFO, check the
> docs and see if you can actually write 16 chars to it without pause.
> To handle 16 chars, it needs to have an extra bit to account for 17
> states (empty and 1 to 16 chars). If this extra state is omitted, it
> could explain the symptoms. Since you have the UART code, it should
> be easy to find the internal in and out counters and monitor them as
> it runs the 16 char case.
>
> > and the 17 character string:
> > constant project_name_stg : string := "f23456789a1234567";
> > yields the output:
> > 23456789a1234567
>
> Yeah, this is the one that sounds like it is overwriting the first
> char or otherwise not being handled correctly. Is the reset to the
> UART being handled? Do you have a image of the simulation waveform?
> I would like to see the same time period as the
> screencap13_firstislast16.png where it shows the writes to the FIFO.
> It would also be useful to see the handshakes between the FIFO and the
> UART. This is an HDL UART, right?
>
> > so it was suggested that I need more settling time in the beginning,
> > so I have now added a delay, you will note in the screencap 15 above
> > is now starting at the 120us time area vs the older version that
> > started
> > at the 1.2us time area.
>
> > No change.
>
> At this point I don't think it is startup issues because the 15 char
> case works. Something is wrong with the FIFO.
>
> Does the UART have a flag from the transmitter shift register to say
> it is empty? If so, you can set up a handshake with that to control
> the write to the FIFO so that the FIFO never has more than one char.
> That should chase away the problem and show that it is in the FIFO
> interface.
>
> I got your email and will give a reply tomorrow.
>
> Rick
I agree its not a startup issue. I have another message that comes
out
(the cindy message) when the user types "123" and that suffers from
the
same symptoms. also the symptoms of strings 17+ are the same,
first character has been destroyed, but the rest queue perfectly
fine.
Most of what else your asking involves the internal workings of the
UART/ bucket brigade Fifo, and that will need to be explored.
it starts with this:
TRANSMIT_UART : entity work.uart_tx
port map
(
data_in => TX_DATA_IN,
write_buffer => TX_WRITE_BUFFER_STB,
reset_buffer => UART_RESET_BUFFER,
en_16_x_baud => UART_EN_16_X_BAUD,
serial_out => RS232_TX_DATA,
buffer_full => TX_BUFFER_FULL,
buffer_half_full => TX_BUFFER_HALF_FULL,
clk => CLK_16_6MHZ
);
which is an instantsiation of this:
http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/uart_tx.vhd
which breaks out to these two:
http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/bbfifo_16x8.vhd
http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/kcuart_tx.vhd
and is documented here:
http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/Docs/UART_Manual.pdf
now the vhd code above, kcuart_tx.vhd details a HDL UART yes? So I
think the
answer to that question is yes...
the reset to the UART being handled? I don't think it makes a
difference, I never send one.
UART flag if empty? doesn't seem to have one that comes out of the
process, but it might
have one internal.
acknowledge the strobe, doesn't look like there is one, I don't see
one.
I'm gonna have to bring out some of the waveforms of the internals of
the UART to answer
some of your screen cap issues.
Article: 138082GrIsH wrote: > I am using spartan-II board..and in my project, i need number of > signals of different frequencies..So i want to divide 50Mz clock of > Spartan-II board to get the clocks of required frequencies...... > So anyone suggest me on How to divide the clock frequency??......... > any help will be greatly appreciated............................. Either use DCMs or use counters generating enable-signals for the faster clocks to act as slower clocks. Avoid using counters to generate your own clocks. Regards, LorenzArticle: 138083
On Feb 5, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Thu, 05 Feb 2009 00:42:41 +0000, Jonathan Bromley wrote:
> > I've written a data
> >generator to create your message strings
> [...]
> >And I've rewritten the top module to use this alongside
> >your existing UART transmitter. You should be able to
> >try it out rather easily and tell me whether it works -
> >I've only tried it in simulation so far, but I'll try
> >it on my little demo board tomorrow.
>
> Yup, it worked just fine. Luckily I remembered to
> correct the baud rate divider to account for the
> 50MHz clock on my dev board, so I actually got it
> to work first time. Ah, the joys of simulation.
>
> Sincere apologies to all you seasoned engineers
> on comp.arch.fpga for my self-satisfaction here.
> I don't do so much with real hardware these days,
> so it's always nice to discover that I haven't
> completely lost my touch :-)
>
> Three noteworthy points:
>
> 1) My design appears to spit out one character of
> garbage at startup. This isn't real; it's caused
> by my PC's UART receiver seeing breaks or other junk
> as a result of the Tx line thrashing about while the
> FPGA is configured. As Antti and I pointed out,
> you need to leave plenty of settling time on the
> serial line after all the indeterminate stuff that
> happens at power-up and configuration. Depending
> on exactly how the RS-232 hardware is wired up on
> your platform, you may be able to engineer your
> way around this by ensuring that the line floats
> to its idle, marking state during configuration.
> On my cheap board, the Tx line goes to a space
> condition (=break) during configuration; I can't
> fix that unless I hack the board.
>
> 2) I note that you run all your UART and data logic
> from a 16.67MHz clock that you get by dividing
> your 100MHz system clock by 6. Have you checked that
> the divided clock is correctly using the clock
> distribution network? I'd be amazed if not, but
> if for any reason that has gone wrong, you could
> get some pretty strange behaviour.
>
> 3) I used the UART's TX_BUFFER_HALF_FULL signal
> to stall my data generator. I did that because
> your strange "15 works, 16 doesn't" symptoms suggested
> that the 16-deep FIFO might not be working quite right.
> To test this I switched over to using TX_BUFFER_FULL
> to throttle the data generator, and everything still
> works just fine. So the FIFO in Ken Chapman's UART
> design is blameless (no surprise there).
> --
> 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.
"3) I used the UART's TX_BUFFER_HALF_FULL signal
to stall my data generator. I did that because
your strange "15 works, 16 doesn't" symptoms suggested
that the 16-deep FIFO might not be working quite right."
I did that yesterday to, using the same thought process. I
hope that means I'm at least thinking in the right directions.
Thanks again for your time in this.
Sincerely,
Jonathan
Article: 138084Hi, I just had the same problem and it has disappeared after I have moved the constants just after the "signal" statements (several lines higher, before "begin" statement) and specified the type of the constant as following: constant system_clock_period :TIME := 10ns; Looks like a bug in ISE... I have 10.1. Downloading Service Pack 3 now, will see if it solve the problem permanently. Cheers, AlexArticle: 138085
If anyone has a hankering for a cheap Darnaw1 there are a couple comming up on our Ebay auction site in the next few days with no reserve. First one is listed as item number 250369084502 and basically works except for the SDRAM that's on board. More details on Darnaw1 - http://www.enterpoint.co.uk/moelbryn/darnaw1.html. John Adair Enterpoint Ltd.Article: 138086
On Feb 3, 8:12=A0am, jhal...@TheWorld.com (Joseph H Allen) wrote: > I'm surprised that the Spartan-6 integrated memory controller does not su= pport > DIMMs. =A0Also surprised that there are no integrated memory controllers = in > Virtex-6. If the memory controller is a hard version of what's in the EDK, you won't want to use it ... -aArticle: 138087
Hi,
I am in the midst of a project where I need a very simple counter
sitting on the bus to count how many cycles a particular program
running on either Xilinx's Microblaze or using the PowerPc (I am
using Xilinx Virtex 4 Ml403 evaluation board). Creating a custom
counter peripheral is not the hard part... the results I am getting
however are somewhat strange to me.
When I have a Microblaze system and have the counter sitting on the
OPB bus, and then I start the counter, and then in C code I do
something like this to test it:
vals[1] = READ_COUNTER();
vals[2] = READ_COUNTER();
vals[3] = READ_COUNTER();
...
vals[n] = READ_COUNTER();
I get values in vals that correspond software taking about 5-7 cycles
to read the counter. Thats fine...
The problem comes when I migrate this functionality to a PowerPC
system, and now my custom counter sits on the PLB bus. This time, with
the same code, the counter reads ~70-75 cycles for each successive
read, basically a full order of magnitude difference, and thus my
results are getting completely screwed up. When I read from a counter
that is still sitting on the OPB bus (thru a PLB to OPB bridge since
the PowerPC sits on the PLB), the results are further increased to
about 75-80 cycles per read. Any ideas why the PLB latency here is so
large?
For reference, I am clocking the Powerpc at 200 MHz while the buses
are clocked at 100 MHz I believe. I am also reading the instructions
from the SRAM, which actually be a contributor to the cycle increase
which I just thought of, but I dont how to check that at this point.
Any help would be great, Thanks,
Scott
Article: 138088On Feb 5, 12:43 pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Feb 5, 2:19 am, rickman <gnu...@gmail.com> wrote: > > > > > On Feb 4, 4:28 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > Hey rick, > > > > let me bring you up to date. > > > > On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote: > > > ~ Given that, I can't see anything in your simulation capture that > > > shows > > > ~ anything wrong. It appears that sending data to the TX FIFO is > > > ~ working. The data sequence seems to be F23456789A123456 which is 16 > > > ~ chars, filling the FIFO as shown by the tx_buffer_full flag going > > > ~ high. After the first char is written to the FIFO I see an enable > > > ~ pulse on uart_en_16_x_baud and one clock later I see the > > > rs232_tx_data > > > ~ go low. This all seems to be working as expected. I assume the > > > baud > > > ~ enable is 16x the actual bit rate, so the simulation time is not > > > long > > > ~ enough to watch the actual data emerge. Have you checked this to > > > see > > > ~ that the simulation is transmitting the data correctly? If the data > > > ~ is being received by the FPGA UART, are all 16 chars received > > > ~ correctly? > > > > That's my big issue, The simulation, seems to show everything is > > > fine, > > > but when I download the code to the board, hook up the UART to my > > > PC terminal session, I get 23456789a123456f, (the F is last rather > > > than > > > first) but the simulation as you noticed as well look perfectly fine: > > > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen... > > > > also through testing I know this to be true: > > > > I make the message string: > > > constant project_name_stg : string := "123456789a12345"; > > > > aka, 15 characters, all is well, I get on my pc terminal: > > > 123456789a12345 > > > > I make it 16 characters: > > > constant project_name_stg : string := "f23456789a123456"; > > > > my output becomes: > > > 23456789a123456f > > > I think Jonathan or someone else suggested that if the F that should > > be the first character is showing up as the last character, this is > > *clearly not* an issue of startup delay. Something is wrong either > > with the way you are writing into the FIFO or perhaps the FIFO code > > itself is not correct. What may well be happening is that the first > > character written into the FIFO is being skipped by the UART. When > > you write exactly 16 characters somehow the UART output counter is > > getting messed up and skips to the second character. Of course this > > is speculation, but the fact that the 15 char message works ok shows > > it is not a startup issue. The 17 char message confuses me though. > > It skips the first char and only outputs 16 chars. Is there an output > > from the UART that acknowledges the strobe when you write to the tx > > fifo (other than the full flag)? If not, then the strobe should be > > accepted at any time. If there is a handshake flag, this needs to be > > checked before writing to the FIFO again that that might explain the > > mixup on 16 or more chars. One last comment on the FIFO, check the > > docs and see if you can actually write 16 chars to it without pause. > > To handle 16 chars, it needs to have an extra bit to account for 17 > > states (empty and 1 to 16 chars). If this extra state is omitted, it > > could explain the symptoms. Since you have the UART code, it should > > be easy to find the internal in and out counters and monitor them as > > it runs the 16 char case. > > > > and the 17 character string: > > > constant project_name_stg : string := "f23456789a1234567"; > > > yields the output: > > > 23456789a1234567 > > > Yeah, this is the one that sounds like it is overwriting the first > > char or otherwise not being handled correctly. Is the reset to the > > UART being handled? Do you have a image of the simulation waveform? > > I would like to see the same time period as the > > screencap13_firstislast16.png where it shows the writes to the FIFO. > > It would also be useful to see the handshakes between the FIFO and the > > UART. This is an HDL UART, right? > > > > so it was suggested that I need more settling time in the beginning, > > > so I have now added a delay, you will note in the screencap 15 above > > > is now starting at the 120us time area vs the older version that > > > started > > > at the 1.2us time area. > > > > No change. > > > At this point I don't think it is startup issues because the 15 char > > case works. Something is wrong with the FIFO. > > > Does the UART have a flag from the transmitter shift register to say > > it is empty? If so, you can set up a handshake with that to control > > the write to the FIFO so that the FIFO never has more than one char. > > That should chase away the problem and show that it is in the FIFO > > interface. > > > I got your email and will give a reply tomorrow. > > > Rick > > I agree its not a startup issue. I have another message that comes > out > (the cindy message) when the user types "123" and that suffers from > the > same symptoms. also the symptoms of strings 17+ are the same, > first character has been destroyed, but the rest queue perfectly > fine. > > Most of what else your asking involves the internal workings of the > UART/ bucket brigade Fifo, and that will need to be explored. > > it starts with this: > > TRANSMIT_UART : entity work.uart_tx > port map > ( > data_in => TX_DATA_IN, > write_buffer => TX_WRITE_BUFFER_STB, > reset_buffer => UART_RESET_BUFFER, > en_16_x_baud => UART_EN_16_X_BAUD, > serial_out => RS232_TX_DATA, > buffer_full => TX_BUFFER_FULL, > buffer_half_full => TX_BUFFER_HALF_FULL, > clk => CLK_16_6MHZ > ); > > which is an instantsiation of this:http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/uart_tx.vhd > > which breaks out to these two: > > http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/bbfifo_16x8.vhdhttp://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/kcuart_tx.vhd > > and is documented here: > > http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/Docs/UART_Manual.pdf > > now the vhd code above, kcuart_tx.vhd details a HDL UART yes? So I > think the > answer to that question is yes... Wow! I know it is possible and will potentially give you the optimum size design, but I have never actually seen a unit that was 100% instantiated. Technically this is VHDL. But for all practical purposes, this is a schematic expressed in text. > the reset to the UART being handled? I don't think it makes a > difference, I never send one. I see that the UART has no reset. The FIFO however, *does* have a reset which is the signal reset_buffer driven by your signal UART_RESET_BUFFER. So that needs to be asserted for a while before the UART is used. Otherwise the FIFO counters may not be in the right state. > UART flag if empty? doesn't seem to have one that comes out of the > process, but it might > have one internal. Yes, there is one coming from the internal UART, but it is not brought out to the higher level interface. It is Tx_complete which is used to drive the fifo_read signal to the FIFO. The handshake between the FIFO and the UART is fifo_read and fifo_data_present. To see what is being loaded into the UART, monitor these signals and the fifo_data_out bus in the simulation. Actually, I think I have lost the thread of what the problem is. Is the simulation working 100% and the real chip is *not* working? If so, looking at the simulation won't tell you a lot. > acknowledge the strobe, doesn't look like there is one, I don't see > one. > > I'm gonna have to bring out some of the waveforms of the internals of > the UART to answer > some of your screen cap issues. Ok, but I think I need a high level overview again. What is working and what is not working? Does the TX serial output look right in all of the simulation? RickArticle: 138089
> I am in the midst of a project where I need a very simple counter >sitting on the bus to count how many cycles a particular program >running on either Xilinx's Microblaze or using the PowerPc (I am >using Xilinx Virtex 4 Ml403 evaluation board). Creating a custom >counter peripheral is not the hard part... the results I am getting >however are somewhat strange to me. > >When I have a Microblaze system and have the counter sitting on the >OPB bus, and then I start the counter, and then in C code I do >something like this to test it: > >vals[1] = READ_COUNTER(); >vals[2] = READ_COUNTER(); >vals[3] = READ_COUNTER(); >... >vals[n] = READ_COUNTER(); > >I get values in vals that correspond software taking about 5-7 cycles >to read the counter. Thats fine... > >The problem comes when I migrate this functionality to a PowerPC >system, and now my custom counter sits on the PLB bus. This time, with >the same code, the counter reads ~70-75 cycles for each successive >read, basically a full order of magnitude difference, and thus my >results are getting completely screwed up. When I read from a counter >that is still sitting on the OPB bus (thru a PLB to OPB bridge since >the PowerPC sits on the PLB), the results are further increased to >about 75-80 cycles per read. Any ideas why the PLB latency here is so >large? > >For reference, I am clocking the Powerpc at 200 MHz while the buses >are clocked at 100 MHz I believe. I am also reading the instructions >from the SRAM, which actually be a contributor to the cycle increase >which I just thought of, but I dont how to check that at this point. >Any help would be great, Thanks, What's the PPC clock frequency vs the bus clock frequency? You are doing an off-chip read. I'm not surprised it takes a long time. Have you timed the same thing on an Intel chip? How many cycles does it take to read a counter from a chip on the PCI bus? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138090
Howdy All, I am looking for a PLB (v4.6) guru for a small project. MUST HAVE in-depth knowledge and understanding of PLB bus. Small job, 1-2 months, remote work ok. Verilog only ! Interested parties please contact me directly: rudolf.usselmann at gmail dot com Thanks, rudiArticle: 138091
Hi all, a very simple question: I've a ML505 board and I'm trying to command its rotary encoder. The code segment of xparameters.h file is: /* Definitions for peripheral XPS_GPIO_1 */ #define XPAR_XPS_GPIO_1_BASEADDR 0x81480000 #define XPAR_XPS_GPIO_1_HIGHADDR 0x8148FFFF #define XPAR_XPS_GPIO_1_DEVICE_ID 4 #define XPAR_XPS_GPIO_1_INTERRUPT_PRESENT 0 #define XPAR_XPS_GPIO_1_IS_DUAL 0 and the ucf file is: #### Rotary Endcoder # Rotary INC A Net Rotary_Encoder_pin<2> LOC = AH30; Net Rotary_Encoder_pin<2> IOSTANDARD=LVCMOS18; Net Rotary_Encoder_pin<2> PULLDOWN; Net Rotary_Encoder_pin<2> SLEW=SLOW; Net Rotary_Encoder_pin<2> DRIVE=2; # Rotary INC B Net Rotary_Encoder_pin<1> LOC = AG30; Net Rotary_Encoder_pin<1> IOSTANDARD=LVCMOS18; Net Rotary_Encoder_pin<1> PULLDOWN; Net Rotary_Encoder_pin<1> SLEW=SLOW; Net Rotary_Encoder_pin<1> DRIVE=2; # Rotary PUSH Net Rotary_Encoder_pin<0> LOC = AH29; Net Rotary_Encoder_pin<0> IOSTANDARD=LVCMOS18; Net Rotary_Encoder_pin<0> PULLDOWN; Net Rotary_Encoder_pin<0> SLEW=SLOW; Net Rotary_Encoder_pin<0> DRIVE=2; With the instruction: XGpio_mGetDataReg (XPAR_XPS_GPIO_1_BASEADDR,1) I can obtain the number of the steps of the rotary encoder but I can't discriminate the rotation direction and the push pin. How could I discriminate between the signals INCA, INCB and PUSH? I need to check the single signal on the three pins AH30, AG30 and AH29 but I dont't khonw what I have to do for. Thanks a lot... DanieleArticle: 138092
On Thu, 5 Feb 2009 21:58:31 -0800 (PST), rickman wrote: [of the Ken Chapman UART design that jleslie48 is using] >Wow! I know it is possible and will potentially give you the optimum >size design, but I have never actually seen a unit that was 100% >instantiated. Technically this is VHDL. But for all practical >purposes, this is a schematic expressed in text. Yes, I was pretty staggered too. It makes heavy use of SRL16s to do the various shifters. It's an amazing piece of bravura optimization, and for something totally re-usable like a UART it's probably a rather good idea to have such a thing handy. >> the reset to the UART being handled? I don't think it makes a >> difference, I never send one. > >I see that the UART has no reset. The FIFO however, *does* have a >reset which is the signal reset_buffer driven by your signal >UART_RESET_BUFFER. So that needs to be asserted for a while before >the UART is used. Otherwise the FIFO counters may not be in the right >state. I think jleslie48's design does indeed assert that FIFO reset appropriately for a few clock cycles at startup. >Actually, I think I have lost the thread of what the problem is. Is >the simulation working 100% and the real chip is *not* working? If >so, looking at the simulation won't tell you a lot. It might be worth re-stating my data point from yesterday: I created a simple message generator design myself, using the same UART macros that jleslie48 uses, and it works just fine both in simulation and in real hardware (Spartan-3 starter kit, 50MHz system clock; the timing report says it's all good for at least 110MHz). So I really don't think it will do the OP any good to try to understand the very tricksy coding of the UARTs. He can use them out-of-the-box with confidence. I didn't get an answer to my question yesterday about whether the OP's 16.7MHz divided clock is correctly distributed on an internal clock net - i.e., has the Xilinx software correctly recognized it to be a clock. Careless use of a divided or gated clock is a likely culprit for mismatch between simulation and hardware. The OP should consider clocking absolutely everything from his 100MHz system clock, and increasing the baud rate divider to the appropriate value. I'm not saying it would make any difference, but at least it would remove one source of uncertainty (oops, sorry, a "known unknown"). -- 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: 138093
Hello , I want to generate a clock of 150Khz from system clock(86.4 Mhz) and requirement is generated 150 khz clock must edge aligned with a reference clock of 150Khz . so what i did , i generated a 150Khz from 86.4Mhz clock by divide factor 576. Finally tried to align that generated clock with ref_clk of 150Khz(on period is one cycle of 86.4Mhz). code is written as follows. simulation in modelsim is correct but in FPGA it seem that clock is generated but jitter is present. Is any other method to do this. I need your suggestions. ---------------------------------------------------------------------------------------- Library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; entity clkdivby576_rec is port( clk : in std_logic; ref_clk : in std_logic; reset : in std_logic; out_clk_rec_data : out std_logic); end clkdivby576_rec; architecture behav of clkdivby576_rec is signal sig_count : natural range 0 to 575 := 0; signal temp : std_logic; begin acq_data_reset : process(reset,ref_clk,sig_count) begin if reset = '1' or sig_count = 1 then temp <= '0'; elsif ref_clk'event and ref_clk = '1' then temp <= '1'; end if; end process acq_data_reset; p0: process(clk,reset) variable clk_var : std_logic :=0; variable count : natural range 0 to 575 := 0; begin if rising_edge(clk) then if temp = '1' then count := 0: end if; if reset = '1' then clk_var := '0'; count := 0; else if count = 575 then count := 0 ; else count := count +1; end if; sig_count <= count : if count >= 287 then clk_var := '0'; else clk_var := '1'; end if; out_clk_rec_data <= clk_var; end if; end if; end process p0; end behav; ---------------------------------------------------------------------Article: 138094
On Feb 6, 10:43=A0am, "J.Ram" <jrgod...@gmail.com> wrote: > Hello , > I want to generate a clock =A0of 150Khz from system clock(86.4 Mhz) and > requirement is generated 150 khz clock must edge aligned with a > reference clock of 150Khz . > so what i did , i generated a 150Khz from 86.4Mhz clock =A0by divide > factor 576. Finally tried to > align that generated clock with ref_clk of 150Khz(on period is one > cycle of 86.4Mhz). > code is written as follows. > simulation in modelsim is correct but in FPGA it seem =A0that clock is > generated but jitter is present. > Is any other method to do this. I need your suggestions. > -------------------------------------------------------------------------= --------------- > > Library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use ieee.std_logic_unsigned.all; > > entity clkdivby576_rec is > port( > clk : in std_logic; > ref_clk : in std_logic; > reset : in std_logic; > out_clk_rec_data : out std_logic); > > end clkdivby576_rec; > > architecture behav of clkdivby576_rec is > signal sig_count : natural range 0 to 575 :=3D 0; > signal temp : std_logic; > > begin > acq_data_reset : process(reset,ref_clk,sig_count) > begin > if reset =3D '1' or sig_count =3D 1 then > temp <=3D '0'; > elsif ref_clk'event and ref_clk =3D '1' then > temp <=3D '1'; > end if; > end process acq_data_reset; > > p0: process(clk,reset) > variable clk_var : std_logic :=3D0; > variable count : natural range 0 to 575 :=3D 0; > begin > if rising_edge(clk) then > if temp =3D '1' then > count :=3D 0: > end if; > if reset =3D '1' then > clk_var :=3D '0'; > count :=3D 0; > else > if count =3D 575 then > count :=3D 0 ; > else > count :=3D count +1; > end if; > sig_count <=3D count : > > if count >=3D 287 then > clk_var :=3D '0'; > else > clk_var :=3D '1'; > end if; > out_clk_rec_data =A0<=3D clk_var; > end if; > end if; > end process p0; > end behav; > --------------------------------------------------------------------- 1) detect EDGE of the ref clock, and use that as sync 2) use DCM to generate higher system clock this will reduce the jitter as the clock will be higher :) AnttiArticle: 138095
I have got Verilog code for a design that has been implemented on Virtex-4. My target is take this design to an ASIC implementation. The issues that I am having right now are related to porting an FPGA based design to an ASIC. When I read this design into Cadence synthesis tools, I get few unresolved references for IDELAYCTRL, ODDR, BUFG, BUFR, BUFIO, BUFGMUX_VIRTEX4. These modules are placed in the design as follows: IDELAYCTRL - connected to DCM ODDR - connected to DCM BUFG - connected to DCM BUFR - connected to SERDES BUFIO - connected to SERDES BUFGMUX_VIRTEX4 - connected to DCM It seems that these modules as xilinx specific and are automatically instantiated in the verilog code when DCM and SERDES components were configured using xilinx tools. Can you please kindly guide on what should I do about these componets as there is no code for these modules in my code directory? Has anyone else experienced this sort of issue before when moving an FPGA-based implementation to an ASIC?Article: 138096
I resolve creating two gpio devices single-channel: one for AG30 pin and one for AH30 pin. In this way I could discriminate the rotation sense checking the data of the two register. Is there a simplier method? How can I check the pins of a single gpio device multichannel? thanksArticle: 138097
On 6 Feb, 10:20, mjunaidel...@gmail.com wrote: > I have got Verilog code for a design that has been implemented on > Virtex-4. My target is take this design to an ASIC implementation. The > issues that I am having right now are related to porting an FPGA based > design to an ASIC. When I read this design into Cadence synthesis > tools, I get few unresolved references for IDELAYCTRL, ODDR, BUFG, > BUFR, BUFIO, BUFGMUX_VIRTEX4. These modules are placed in the design > as follows: > > IDELAYCTRL =A0 =A0 =A0 =A0 =A0 =A0 - connected to DCM > > ODDR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- connected to DCM > > BUFG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - connected to DCM > > BUFR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - connected to SERDE= S > > BUFIO =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- connected to SERDE= S > > BUFGMUX_VIRTEX4 - connected to DCM > > It seems that these modules as xilinx specific and are automatically > instantiated in the verilog code when DCM and SERDES components were > configured using xilinx tools. Can you please kindly guide on what > should I do about these componets as there is no code for these > modules in my code directory? Has anyone else experienced this sort of > issue before when moving an FPGA-based implementation to an ASIC? Yes these are all Xilinx specific blocks that you will not find in an ASIC library. However, I suspect your biggest problem is the instantiation of the DCM and SERDES blocks as you will not have these in your ASIC library either. What is your plan for those? If you use different IP for these, you will not need the cells listed above. Cheers, JonArticle: 138098
On Fri, 06 Feb 2009 04:25:04 -0600, "charlie78" wrote: >I resolve creating two gpio devices single-channel: >one for AG30 pin and one for AH30 pin. >In this way I could discriminate the rotation sense >checking the data of the two register. > >Is there a simplier method? I would say that it depends on the likely speed of the encoder. If it is slow (for example, a front panel control that will be manually rotated and has quite low resolution, or a mouse scroll wheel) then it makes sense to use two GPIO pins and track the rotation in software on your Microblaze. But if the encoder will generate more than about 100 pulses per second it probably makes more sense to use a hardware decoder. That would be appropriate, for example, in motion control or velocity sensing applications where you might expect thousands of pulses per second. If you Google for "quadrature decoder" you should get plenty of hits for VHDL, Verilog and schematic-based designs. You should expect to get a position output as an 8-bit (or wider) number that you can read at any time using a multi-bit GPIO port. A quadrature decoder with an 8-bit double-buffered position register should be a fairly small hardware design - no more than 30 LUT/FF blocks. >How can I check the pins of a single gpio device multichannel? Sorry, I don't know quite what you mean by this. -- 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: 138099
Hi, 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? I am using Quartus II targeting a Cyclone device. There are no errors or warnings given, I just want to make sure the design is not relying on undefined behaviour. Thanks R.
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