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
>so far i manage to taken care of the reciever part of the rs232 bus >controller, but im still having problem with transmitter part.. >any idea how to come out with the state machine of transmitter part ? ... Most people think the receiver is harder.... Tx is comparatively easy. Load the 8-bit data you want to send into a 10-bit shift register, like so: bit #... 9 8 7 6 5 4 3 2 1 0 contents 1 d7 d6 d5 d4 d3 d2 d1 d0 0 Drive bit 0 of this register out to the RS-232 level shifter. The fact there's now a 0 in this position will create your start bit. Now clock the register as a shift register, pushing its more significant bits rightwards towards its least significant bits, and being sure to shift in '1' at the left end every time: bit #........ 9 8 7 6 5 4 3 2 1 0 initial value 1 d7 d6 d5 d4 d3 d2 d1 d0 0 after 1 clock 1 1 d7 d6 d5 d4 d3 d2 d1 d0 after 2 clocks 1 1 1 d7 d6 d5 d4 d3 d2 d1 ... So you can see that the output end (right-hand end) step- by-step gives you first the start bit 0, then d0, then d1 and so on... after 7 clocks 1 1 1 1 1 1 1 1 d7 d6 after 8 clocks 1 1 1 1 1 1 1 1 1 d7 after 9 clocks 1 1 1 1 1 1 1 1 1 1 And now you have your stop bit appearing at the output. The fact that the whole register now contains all-1 means two things: 1) you can use this as a "ready" indication to say that it's now safe to load a new value on the next clock; 2) you don't need to stop; you can continue shifting, and the line will correctly continue to idle, if there is no new data. Sounds easy to me. No counters or (explicit) state machines required. -- 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: 136276
On Nov 8, 10:23=9Aam, "guestuser1" <guestus...@nowhere.net> wrote: > A year ago, I heard Synplicity's (RTL synth) Systemverilog support was > terrible. > > Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces, > enums, typedefs, unique/priority case, always_comb/always_ff, etc.) > Not everything yet, but very usable. > > So how does the current version of Synplicity compare, in terms of > Systemverilog language support? Well, Synplicity had been acquised by Synopsys last year. Synopsys, in opposite of Cadence and Mentor, did't adopt SV in own products till to last time. While Cadence and Mentor collaborated into SV support and moved forward with OVM initiative, Synopsys concentrates into conventional HDL support only. Started from QuartusII v7.2 I develop my altera projects in SV only. QII has a practically usefull synthesable SV subset support. I've found only one annoyed problem - SoPCBuilder don't still deal with SV modules :( Digitally yours, =EDikhail TsvetkovArticle: 136277
> after 7 clocks 1 1 1 1 1 1 1 1 d7 d6 > after 8 clocks 1 1 1 1 1 1 1 1 1 d7 > after 9 clocks 1 1 1 1 1 1 1 1 1 1 > >And now you have your stop bit appearing at the output. >The fact that the whole register now contains all-1 >means two things: >1) you can use this as a "ready" indication to say that > it's now safe to load a new value on the next clock; Nope. What if d7 is a 1? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136278
On Sun, 09 Nov 2008 14:22:45 -0600, Hal Murray wrote: >Nope. What if d7 is a 1? Urrrm, yes. That'll teach me not to post half-baked recollections of earlier projects without thinking properly :-) Thanks for the correction. The *correct* implementation of that idea is to shift in zeros instead of 1s: bit #........ 9 8 7 6 5 4 3 2 1 0 initial value 1 d7 d6 d5 d4 d3 d2 d1 d0 0 after 1 clock 0 1 d7 d6 d5 d4 d3 d2 d1 d0 after 2 clocks 0 0 1 d7 d6 d5 d4 d3 d2 d1 ... after 7 clocks 0 0 0 0 0 0 0 1 d7 d6 after 8 clocks 0 0 0 0 0 0 0 0 1 d7 after 9 clocks 0 0 0 0 0 0 0 0 0 1 Then detect the "000000001" condition and use it to STOP the shifting process, as well as enabling loading of the register with "1dddddddd0" when the next data becomes available. Sincere apologies. [retires to bathroom to wipe egg from face] -- 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: 136279
On 7 nov, 18:31, Francois Choquette <fchoque...@gmail.com> wrote: > > Well I think that designing a face-recognition system in VHDL (or > > Verilog) would be a huge waste of time and it would be really hard to > > do. There are tools for that, to automate conversion from Matlab to > > HDL (AccelDSP, system generator). I'm pretty sure that there are FPGA- > > neutral tools too for Matlab (that would work on both Altera and > > Xilinx) > > Such as Synplify DSP, from Synplicity. =A0Supports all major devices > vendors, even ASIC technology. > > Francois Choquette Yeah but AFAIK, there are still more features in AccelDSP than in SynplifyDSP. Such as Matrix operations for example. That's probably overkill for most applications though.Article: 136280
Jonathan Bromley wrote: > Urrrm, yes. That'll teach me not to post > half-baked recollections of earlier projects > without thinking properly :-) Thanks for the > correction. To be fair, I would call it a fully-baked idea missing only a bit of frosting on one corner. The most painful part of any design process is getting from that blank page to a sketch of some plausible design strategy. Fixing the bits around the edges, while compiling code or running a sim, is fun by comparison. I would also point out that text comments as in your example > bit #........ 9 8 7 6 5 4 3 2 1 0 > initial value 1 d7 d6 d5 d4 d3 d2 d1 d0 0 > after 1 clock 0 1 d7 d6 d5 d4 d3 d2 d1 d0 > after 2 clocks 0 0 1 d7 d6 d5 d4 d3 d2 d1 > ... > after 7 clocks 0 0 0 0 0 0 0 1 d7 d6 > after 8 clocks 0 0 0 0 0 0 0 0 1 d7 > after 9 clocks 0 0 0 0 0 0 0 0 0 1 are just the thing to head up a block of code. Thoughts are always more fleeting than I expect. I applaud Jonathan and other posters here for having the simple bravery to share their raw ideas, or the polite scrutiny of such ideas, for the benefit of unknown readers. -- Mike Treseler (full disclosure: I have been merrily stealing Mr Bromley's ideas since i discovered usenet ;)Article: 136281
On Nov 7, 11:28=A0pm, KJ <lkj...@gmail.com> wrote: > Hi everyone. > > I have a Xilinx ML555 and Linux as OS. > The job assigned to me is =A0linux programming for "Data transfer > between CPU and FPGA over PCI bus". > Someone already did the similar thing. Please help me. > > General flow is like this. > (1) CPU sends data to FPGA > (2) FPGA do computations > (3) FPGA gives it back to CPU > > What I want to ask is following. > > (1) This is the first time for Linux programming. > =A0 =A0 =A0Where can I get the sample codes or reference? > > (2) I think that initially FPGA chip is not configured. > =A0 =A0 So How to configure it? =A0( I mean that if I have a bitstream fi= le > for FPGA, How can I configure FPGA with it?) > > (3) If you have already done with similar job, plz give me an advice > about how to proceed. > =A0 =A0 I have to do it myself, so even a little advice is big help for > me. > > Thanks in advance. I am assuming you want to transfer data between CPU and FPGA using PCIe. Regarding sample driver, any PCI driver should suffice provided you know the Vendor ID / Device ID that is being used in PCIe HardIP and it is programmable. After that, you can use the BAR0 and BAR1 regions available in PCI Config Space to transfer data from and to a FPGA from a CPU. So the PCI Linux driver writes and reads from BAR0 and BAR1 and based on some assumptions or some encoding in BAR0 or BAR1 you come up with, you can make sure whether computation in the FPGA is done or is in progress etc. So in order to achieve this, basically you need to create some memory inside the FPGA so that any request that comes to BAR0 or BAR1 goes to that memory and is then sent to whatever computational block that you have in FPGA. --paragArticle: 136282
Hi, I am using the FIR compiler v8.0 in Quartus to design a lowpass FIR filter, the .vhd VHDL file and other files are generated by the tool, but I get an "unknown error" with the .bsf Block Symbol File, and this file isn't generated, anyone come across this type of error? cheers, JamieArticle: 136283
On 2008-11-10, mynewlifever@yahoo.com.cn <mynewlifever@yahoo.com.cn> wrote: > In the report, route use 88.5% timing budget, how to make route use > fewer timing budget. reset_n is an output of BUFG. If I have a synchronuos reset I usually solve this problem by adding a couple of registers to the reset signal. This means that the reset signal will not have any immediate effect, but I don't really care if the chip will reset itself in 3 nanoseconds or 15 nanoseconds. By the way, is your reset signal synchronuos with your clock signal or not? If it isn't, you need to synchronize it with a couple of flip-flops regardless of the above advice. /AndreasArticle: 136284
axr0284 wrote: > On Nov 3, 8:35 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: >> On 31 Okt., 13:58, axr0284 <axr0...@yahoo.com> wrote: >> >>> 1) If my module detects an address parity error but bit 8 in the >>> command register used to turn on system error signaling is set to 0, >>> does my system >>> a) ignore the command >>> b) Responds normally ignoring parity checking >>> c) Takes possession of the request by asserting DEVSEL and then sends >>> back a target abort. >>> The PCI spec is not too clear about this particular case. >> Actually it is very clear. Section 3.8.2.2 in Revision 2.1 of the spec >> states: >> "A selected agent that detects an address parity error should do one >> of the following: claim the cycle and terminate as though the address >> was correct, claim the cycle and terminate with Target-Abort, or not >> claim the cycle and let it terminate the Master-Abort." >> >> So you have the choice of a), b) and c). >> I do not have a newer version of the spec, maybe it became more >> restrictive. >> I still believe that b) is stupid, because you do not even know >> whether you should perform a read or a write access. >> >> Kolja Sulimma > > Thanks for the answer. I've decided to go with Target Abort on that > one since on my implementation there is only 1 master and 1 slave on > the bus. > Amish However, I would argue that in the general case (a) makes the most sense, simply because you don't know what the address was supposed to look like, and therefore if it was *meant* to be directed to you. -hpaArticle: 136285
David Brown wrote: > > My understanding of Altera's FPGAs is that they have pretty much given > up on using ARM hard-core processors, because the Nios / Nios II was > actually faster for real use - the flexibility of memory bus > arrangements, custom instructions, etc., meant that the space taken by > the ARM core was simply not worth it. It would still be nice to have more chips with combination microcontroller and small FPGA at the low end, as that is often a useful mix as opposed to having to have a much bigger FPGA. Aiming this at the high-end CPLD markets (with features such as onboard flash, 5V tolerance, etc.) would be especially nice. -hpaArticle: 136286
I have a XST board v3.0 with a spartan XCS3100c. i want to use that board to transfer the data from and to the PC using USB. can you please help me with some demo program that explains the use of USB for sending the data. I dont know what connections to make. please tell me from scratch. thanks in advance atulArticle: 136287
Leon schrieb: > On 7 Nov, 19:26, Benjamin Couillard <benjamin.couill...@gmail.com> > wrote: >> On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote: >> >> >> >>> On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com> >>> wrote: >>>> On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote: >>>>> On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com> >>>>> wrote: >>>>>> On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote: >>>>>>> What are your views onhttp://scratchpad.wikia.com/wiki/TileraMulticore >>>>>>> as a replacement for FPGA's ? >>>>>>> http://www.tilera.com/solutions/digital_baseband.php >>>>>>> The current architecture for base stations fall short of delivering >>>>>>> the performance, the low latency and the flexibility customers need. >>>>>>> To meet the requirements, wireless equipment providers design complex >>>>>>> systems with FPGA, ASIC, DSP and processors with each component >>>>>>> requiring special tools in a customized development environment. This >>>>>>> leads to a long development cycle, sometimes years, before >>>>>>> applications can be productized. Changes in standards also impact >>>>>>> providers because such systems are inflexible-upgrades can be a slow >>>>>>> and expensive process. >>>>>>> What providers seek is an uncomplicated, well-designed, architecture >>>>>>> that yields good performance. Tilera's processors provide a low >>>>>>> latency single solution that integrates many functions seamlessly in a >>>>>>> single processor and uses C/C++ to program their applications with >>>>>>> industry standard tools. The familiar tools enable customers to >>>>>>> preserve their software investments, replace a number of disparate >>>>>>> programming methodologies with one standard programming environment, >>>>>>> and gain the flexibility they need to support evolving protocols and >>>>>>> ever-increasing demands for service >>>>>> It seems to be similar to XMOS devices. I suppose that it could >>>>>> replace FPGAs in some applications. However, it's still a much coarser >>>>>> architecture than an FPGA. There's still only 64 processing units, >>>>>> while a Virtex-5 can have about 20 000 slices and a couple of PPC >>>>>> processors. In the end, I think that since FPGAs are much more >>>>>> flexible, they have the upper hand. Plus with tools like system >>>>>> generator, AccelDSP and Simulink, low-level HDL coding can be skipped, >>>>>> and the engineer can focus more on applications and less on the "bit- >>>>>> level" of things. >>>>>> Plus I suppose that with a high-capacity FPGA, one could emulate a >>>>>> Tilera-like device with 64 processing units. Maybe the future's there, >>>>>> take the Tilera (or Xmos) concept and implement it in a FPGA. >>>>>> My 2 cents >>>>> They will cost more, be much harder to use, use a lot more power and >>>>> won't be any faster. >>>>> Leon >>>> THe point is not that it will be faster, is that it'll be much more >>>> versatile since you won't be stuck with a fixed architecture >>> You won't have 64k per core, and what about stuff like 100 MHz I/Os, >>> hardware threads switching in one cycle, and 3.2 Gb/s full duplex >>> links between cores? >>> Leon >> You raise some good points. >> But, I was just making the point that you could implement some sort of >> "xmos-like" architecture in a big FPGA. While you wouldn't have 64k >> per core , you would certainly be able to have 3.2 Gb/s full duplex >> (32 bits @ 100 MHz). >> >> But anyay, I think that FPGAs are there to stay and they have a big >> future in front of them. There might be some applications where >> they'll be replaced by faster, cheaper technologies, but the reverse >> is also true. > > They won't replace them completely, of course, but there will be many > applications where the ease of development (a C-like language with > compilation and testing in a few seconds) and low cost will see them > being used in place of FPGAs, and in conjunction with them. One > application I've heard of uses a CPLD as an XLink interface to an XMOS > chip, and I'm thinking of using an FPGA between an RF ADC and the XMOS > chip for a software defined radio. > > Leon When I talked to the XMOS guys they told me about the programmable and highly flexible IOs. That suggested somehow that you should not need an FPGA to glue the ADC to the XMOS chip. Can you tell us why this cannot be done? -MarkusArticle: 136288
I use xilinx virtex 5 to do design, and after place&route, some path
didnot meet timing constraint. All of these paths are relevant to the
reset_n. reset_n is a synchronization global reset signal. I donot
know how to solve this problem, so I copy one of these report, please
help to analyze.
In the report, route use 88.5% timing budget, how to make route use
fewer timing budget. reset_n is an output of BUFG.
BUFG reset
( .I (reset_int),
.O(reset_n)
);
Place&route report:
Maximum Data Path: reset_gen/reset_int to data_path/dp_pre_ins/
dp_pre_psr/psr_cs_FSM_FFd16
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.450 reset_gen/reset_int
net (fanout=1) 1.437 reset_gen/reset_int
Tbgcko_O 0.250 reset_gen/reset
net (fanout=548) 2.703 reset_n
Tilo 0.094 data_path/dp_pre_ins/dp_pre_psr/
fifo_dat<23>4
net (fanout=1) 1.653 data_path/dp_pre_ins/dp_pre_psr/
fifo_dat<23>4
Tilo 0.094 data_path/dp_pre_ins/dp_pre_psr/
fifo_dat<23>24
net (fanout=24) 1.900 data_path/dp_pre_ins/dp_pre_psr/
fifo_dat<23>
Tilo 0.094 data_path/dp_pre_ins/dp_pre_psr/
psr_cs_cmp_eq00011
net (fanout=3) 0.597 data_path/dp_pre_ins/dp_pre_psr/N254
Tilo 0.094 data_path/dp_pre_ins/dp_pre_psr/
psr_cs_cmp_eq000121
net (fanout=3) 0.762 data_path/dp_pre_ins/dp_pre_psr/N287
Tilo 0.094 data_path/dp_pre_ins/dp_pre_psr/
psr_cs_cmp_eq00012
net (fanout=2) 0.143 data_path/dp_pre_ins/dp_pre_psr/
psr_cs_cmp_eq0001
Tas 0.026 data_path/dp_pre_ins/dp_pre_psr/
psr_cs_FSM_FFd16-In1
data_path/dp_pre_ins/dp_pre_psr/
psr_cs_FSM_FFd16
---------------------------- ---------------------------
Total 10.391ns (1.196ns logic, 9.195ns route)
(11.5% logic, 88.5% route)
--------------------------------------------------------------------------------
Slack: -5.361ns (requirement - (data path - clock
path skew + uncertainty))
Source: reset_gen/reset_int (FF)
Destination: data_path/dp_pre_ins/dp_pre_psr/
psr_cs_FSM_FFd4 (FF)
Requirement: 5.000ns
Data Path Delay: 10.390ns (Levels of Logic = 7)
Clock Path Skew: 0.184ns (1.807 - 1.623)
Source Clock: clk_156_raw rising at 0.000ns
Destination Clock: glb_clk_156 rising at 5.000ns
Clock Uncertainty: 0.155ns
Article: 136289H. Peter Anvin wrote: > David Brown wrote: >> My understanding of Altera's FPGAs is that they have pretty much given >> up on using ARM hard-core processors, because the Nios / Nios II was >> actually faster for real use - the flexibility of memory bus >> arrangements, custom instructions, etc., meant that the space taken by >> the ARM core was simply not worth it. > > It would still be nice to have more chips with combination > microcontroller and small FPGA at the low end, as that is often a useful > mix as opposed to having to have a much bigger FPGA. Aiming this at the > high-end CPLD markets (with features such as onboard flash, 5V > tolerance, etc.) would be especially nice. > > -hpa I'd like to see something like that too. The only one I can think of is Atmel's FPSLIC's, which are an FPGA with an AVR core. But they don't really do the same thing - the AVR core is like an add-on hard-core in a small FPGA. I'd prefer something that had the convenience and easy of use of a normal AVR device (or similar small micro), but with some programmable logic built-in to off-load the processor for fast I/O or calculation acceleration. A hundred or so CPLD macrocells would be enough for many situations.Article: 136290
On Sun, 09 Nov 2008 15:21:11 -0800, Mike Treseler wrote: >I would also point out that text comments >as in your example [...] >are just the thing to head up a block of code. >Thoughts are always more fleeting than I expect. Ah, if only everyone agreed with that :-) I'm just coming to the end of a session working alongside a very, very smart young designer whose only noticeable fault is the total lack of useful commentary in his code. Initially I thought that was just bull-headed idiocy on his part, but now I recognise that his thoughts are probably a lot less fleeting than mine... so he doesn't (yet) need comments for himself; he can just REMEMBER stuff. Me, I have various prosthetics (notebook, computer, ...) to do duty for my rapidly failing memory. My own poor memory probably encourages me to write comments for myself that are also useful for other readers. I hereby rest the case for the defence ... -- 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: 136291
>I use xilinx virtex 5 to do design, and after place&route, some path >didnot meet timing constraint. All of these paths are relevant to the >reset_n. reset_n is a synchronization global reset signal. I donot >know how to solve this problem, so I copy one of these report, please >help to analyze. Do you really have only one clock in your design? Do you understand metastability? >In the report, route use 88.5% timing budget, how to make route use >fewer timing budget. reset_n is an output of BUFG. > BUFG reset > ( .I (reset_int), > .O(reset_n) > ); Reset gets discussed here more than occasionally. You might find something useful in the archives. The usual approach is to treat an external reset as an asynchronous signal and synchronize it (pair of FFs) locally at each state machine. It may take some extra logic if your design depends upon a chain of state machines coming out of reset together. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136292
>>so far i manage to taken care of the reciever part of the rs232 bus
>>controller, but im still having problem with transmitter part..
>>any idea how to come out with the state machine of transmitter part ?
...
>
>Most people think the receiver is harder....
>
>Tx is comparatively easy. Load the 8-bit data you want to send
>into a 10-bit shift register, like so:
>
> bit #... 9 8 7 6 5 4 3 2 1 0
> contents 1 d7 d6 d5 d4 d3 d2 d1 d0 0
>
>Drive bit 0 of this register out to the RS-232 level shifter.
>The fact there's now a 0 in this position will create your
>start bit. Now clock the register as a shift register,
>pushing its more significant bits rightwards towards its
>least significant bits, and being sure to shift in '1' at
>the left end every time:
>
> bit #........ 9 8 7 6 5 4 3 2 1 0
> initial value 1 d7 d6 d5 d4 d3 d2 d1 d0 0
> after 1 clock 1 1 d7 d6 d5 d4 d3 d2 d1 d0
> after 2 clocks 1 1 1 d7 d6 d5 d4 d3 d2 d1
> ...
>
>So you can see that the output end (right-hand end) step-
>by-step gives you first the start bit 0, then d0, then d1
>and so on...
>
> after 7 clocks 1 1 1 1 1 1 1 1 d7 d6
> after 8 clocks 1 1 1 1 1 1 1 1 1 d7
> after 9 clocks 1 1 1 1 1 1 1 1 1 1
>
>And now you have your stop bit appearing at the output.
>The fact that the whole register now contains all-1
>means two things:
>1) you can use this as a "ready" indication to say that
> it's now safe to load a new value on the next clock;
>2) you don't need to stop; you can continue shifting,
> and the line will correctly continue to idle, if
> there is no new data.
>
>Sounds easy to me. No counters or (explicit) state
>machines required.
>--
>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.
>
Hi there,
In response to your msg at
http://www.fpgarelated.com/usenet/fpga/show/80222-1.php,
I would like to ask you about the coding for it. I do understand the
concept of it. But, how do I shift it right so that every clock cycle the
LSB will be transferred out ? I mean i know how to shift it to the right
but, the problem i see is that start bit might be ignored as I shifted the
iTxdbuffer before i actually send the LSB of iTxd buffer to the TxD
here are my codes ,. .. do you see any errrors about this ? ...how can i
edit from here...
comments are appreciated... thanks
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity Rs232Txd is
port( Reset, Send, Clock16x: in std_logic;
DataIn: in std_logic_vector(7 downto 0);
Txd: out std_logic);
end Rs232Txd;
architecture Rs232Txd_Arch of Rs232Txd is
attribute enum_encoding: string;
-- state definitions
type stateType is (stIdle, stData, stStop, stTxdCompleted);
attribute enum_encoding of stateType: type is "00 01 11 10";
signal presState: stateType;
signal nextState: stateType;
signal iSend, iReset, iClock1xEnable, iEnableTxdBuffer, iEnableShift:
std_logic;
signal iTxdBuffer: std_logic_vector (9 downto 0);
signal iClockDiv: std_logic_vector (3 downto 0);
signal iClock1x: std_logic;
signal iNoBitsSent: std_logic_vector (3 downto 0);
begin
process (Clock16x)
begin
if Clock16x'event and Clock16x = '1' then
if Reset = '1' or iReset = '1' then
iSend <= '0';
iEnableTxdBuffer <= '0';
iEnableShift <= '0';
iClock1xEnable <= '0';
iClockDiv <= (others=>'0');
end if;
if Send = '1' or iSend = '1' then
iClock1xEnable <= '1';
end if;
if iClock1xEnable = '1' then
iClockDiv <= iClockDiv + '1';
end if;
if iEnableTxdBuffer = '1' then
iTxdBuffer <= '1' & DataIn & '0'; -- inserting start bit and stop bit
end if;
end if;
end process;
iClock1x <= iClockDiv(3);
process (iClock1xEnable, iClock1x)
begin
if iClock1xEnable = '0' then
iNoBitsSent <= (others=>'0');
presState <= stIdle;
elsif iClock1x'event and iClock1x = '1' then
iNoBitsSent <= iNoBitsSent + '1';
presState <= nextState;
end if;
if iClock1x'event and iClock1x = '1' then
if iEnableShift = '1' then
iTxdBuffer <= '0' & iTxdBuffer(9 downto 1);
end if;
end if;
end process;
Txd <= iTxdBuffer(0);
process (presState, iClock1xEnable, iNoBitsSent)
begin
-- signal defaults
iReset <= '0';
iEnableTxdBuffer <= '0';
iEnableShift <= '0';
case presState is
when stIdle =>
if iClock1xEnable = '1' then
iEnableTxdBuffer <= '1';
nextState <= stData;
else
nextState <= stIdle;
end if;
when stData =>
i
if iNoBitsSent = "1010" then
iEnableShift <= '0';
nextState <= stStop;
else
iEnableShift <= '1';
nextState <= stData;
end if;
when stStop =>
nextState <= stTxdCompleted;
when stTxdCompleted =>
iReset <= '1';
nextState <= stIdle;
end case;
end process;
end Rs232Txd_Arch;
Article: 136293On Nov 5, 11:12=A0pm, markmcma...@hotmail.com wrote: > > After debugging the problem further, I am sure I can open, read and > > close files from the CF card now. Everything is good while I am > > reading files with <=3D 12KBytes. The previously mentioned exception > > occurs when I read the next byte of the open file. > > Any ideas? > > > Thanks- Hide quoted text - > > Try increasing your stack size. Thanks Mark, I increased the stack size to the size of the read file from the CF card and it worked. Does it make sense to keep the stack size at near 1MB? Why does this actually happen? The first though would make me think that since the buffer that I am using to store a chunk of data read from a CF file is re-used during the next read in a loop, the stack size should not grow that much. However, I am missing something here. Thank youArticle: 136294
On Nov 5, 5:44=A0am, Matthias Alles <REMOVEallesCAPIT...@NOeit.SPAMuni- kl.de> wrote: > Hi! > > You could also try the vga controller contained in the Genode FX project > (fpga-graphics.org). It supports double buffering, vertical blank > interrupts and fast clearing of memory. Timing and resolution are > programmable. It requires an MPMC core for fetching the pixel data from > external RAM. > But it currently uses a color depth of 16 bits (RGB=3D565) as well. > > Matthias > > > Is TFT Controller v1.00a for Microblaze 7 the easiest way to output > > video buffer to VGA screen? I was thinking of writing my own VGA > > controller, reading a line buffer stored in BRAM and having two copies > > of it to update one while the other one is read by the VGA controller. > > However, it seems as it is readily available as a pcore for smaller > > resolutions of 640x480, 18-bit bitmaps. > > > Any comments? > > I would have to cut down on the originally planned resolution of 24- > > bits if I go with this option. > > > Thanks Thanks Matthias, that looks like an interesting project!Article: 136295
Hi, I am facing an issue of accessing the registers of a peripheral sitting on the DCR bus via PLBV46 to DCR Bridge and uBlaze. The uBlaze is on the PLB bus. The bridge is a slave on PLB and a master on DCR. Please see below for a snippet of the .mhs file. Since my peripheral has the C_DCR_BASEADDR = 0b0000000000, I assume it is register 0 on the PLB2DCR bridge and I can simply access it by looking at the base address of the PLB2DCR. For example, write_adress (0x87000000, value1) write_adress (0x87000004, value2) Does it make sense? BEGIN plbv46_dcr_bridge PARAMETER INSTANCE = plbv46_dcr_bridge_0 PARAMETER HW_VER = 1.00.a PARAMETER C_BASEADDR = 0x87000000 PARAMETER C_HIGHADDR = 0x8700ffff BUS_INTERFACE SPLB = mb_plb BUS_INTERFACE MDCR = dcr_v29_0 END BEGIN xps_tft PARAMETER INSTANCE = xps_tft_0 PARAMETER HW_VER = 1.00.a PARAMETER C_DCR_SPLB_SLAVE_IF = 0 PARAMETER C_TFT_INTERFACE = 0 PARAMETER C_DEFAULT_TFT_BASE_ADDR = 0x10800000 PARAMETER C_DCR_BASEADDR = 0b0000000000 PARAMETER C_DCR_HIGHADDR = 0b0000000011 BUS_INTERFACE MPLB = mb_plb BUS_INTERFACE SDCR = dcr_v29_0 PORT TFT_VSYNC = VGA_VSYNCH PORT TFT_HSYNC = VGA_HSYNCH PORT TFT_VGA_CLK = VGA_OUT_PIXEL_CLOCK PORT SYS_TFT_Clk = tft_clk PORT TFT_DE = VGA_OUT_BLANK_Z PORT DCR_Rst = sys_bus_reset PORT DCR_Clk = sys_clk_s PORT TFT_VGA_R = VGA_OUT_RED PORT TFT_VGA_G = VGA_OUT_GREEN PORT TFT_VGA_B = VGA_OUT_BLUE END Thank you in advanceArticle: 136296
I have an LX50T based design with an SPI Flash for configuration memory. It programs OK (the code runs) but Verify always fails. The Flash contents clearly are OK otherwise the code wouldn't run so does anyone have any ideas why the Verify will report as "Failed"? TIA, Rog.Article: 136297
when i completed the edk base system builder wizard with EDK 8.2i and connected spartan 3e starter kit and downloaded the bitstream with Test_app_memory.c and .elf files i didn't seen anything on my hyperterminal with all hardware kit and wire attached with baud rate of 9600 as standard one. will any body suggest what would be the cause for this happen, all suggestions arew valuable for me.Article: 136298
On 10 Nov, 07:22, Markus <n...@nowhere.org> wrote: > Leon schrieb: > > > > > On 7 Nov, 19:26, Benjamin Couillard <benjamin.couill...@gmail.com> > > wrote: > >> On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote: > > >>> On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com> > >>> wrote: > >>>> On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote: > >>>>> On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com> > >>>>> wrote: > >>>>>> On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote: > >>>>>>> What are your views onhttp://scratchpad.wikia.com/wiki/TileraMult= icore > >>>>>>> as a replacement for FPGA's ? > >>>>>>>http://www.tilera.com/solutions/digital_baseband.php > >>>>>>> The current architecture for base stations fall short of deliveri= ng > >>>>>>> the performance, the low latency and the flexibility customers ne= ed. > >>>>>>> To meet the requirements, wireless equipment providers design com= plex > >>>>>>> systems with FPGA, ASIC, DSP and processors with each component > >>>>>>> requiring special tools in a customized development environment. = This > >>>>>>> leads to a long development cycle, sometimes years, before > >>>>>>> applications can be productized. Changes in standards also impact > >>>>>>> providers because such systems are inflexible-upgrades can be a s= low > >>>>>>> and expensive process. > >>>>>>> What providers seek is an uncomplicated, well-designed, architect= ure > >>>>>>> that yields good performance. Tilera's processors provide a low > >>>>>>> latency single solution that integrates many functions seamlessly= in a > >>>>>>> single processor and uses C/C++ to program their applications wit= h > >>>>>>> industry standard tools. The familiar tools enable customers to > >>>>>>> preserve their software investments, replace a number of disparat= e > >>>>>>> programming methodologies with one standard programming environme= nt, > >>>>>>> and gain the flexibility they need to support evolving protocols = and > >>>>>>> ever-increasing demands for service > >>>>>> It seems to be similar to XMOS devices. I suppose that it could > >>>>>> replace FPGAs in some applications. However, it's still a much coa= rser > >>>>>> architecture than an FPGA. =A0There's still only 64 processing uni= ts, > >>>>>> while a Virtex-5 can have about 20 000 slices and a couple of PPC > >>>>>> processors. In the end, I think that since FPGAs are much more > >>>>>> flexible, they have the upper hand. Plus with tools like system > >>>>>> generator, AccelDSP and Simulink, low-level HDL coding can be skip= ped, > >>>>>> and the engineer can focus more on applications and less on the "b= it- > >>>>>> level" of things. > >>>>>> Plus I suppose that with a high-capacity FPGA, one could emulate a > >>>>>> Tilera-like device with 64 processing units. Maybe the future's th= ere, > >>>>>> take the Tilera (or Xmos) concept and implement it in a FPGA. > >>>>>> My 2 cents > >>>>> They will cost more, be much harder to use, use a lot more power an= d > >>>>> won't be any faster. > >>>>> Leon > >>>> THe point is not that it will be faster, is that it'll be much more > >>>> versatile since you won't be stuck with a fixed architecture > >>> You won't have 64k per core, and what about stuff like 100 MHz I/Os, > >>> hardware threads switching in one cycle, and 3.2 Gb/s full duplex > >>> links between cores? > >>> Leon > >> You raise some good points. > >> But, I was just making the point that you could implement some sort of > >> "xmos-like" architecture in a big FPGA. While you wouldn't have 64k > >> per core , you would certainly be able to have 3.2 Gb/s full duplex > >> (32 bits @ 100 MHz). > > >> But anyay, I think that FPGAs are there to stay and they have a big > >> future in front of them. There might be some applications where > >> they'll be replaced by faster, cheaper technologies, but the reverse > >> is also true. > > > They won't replace them completely, of course, but there will be many > > applications where the ease of development (a C-like language with > > compilation =A0and testing in a few seconds) and low cost will see them > > being used in place of FPGAs, and in conjunction with them. One > > application I've heard of uses a CPLD as an XLink interface to an XMOS > > chip, and I'm thinking of using an FPGA between an RF ADC and the XMOS > > chip for a software defined radio. > > > Leon > > When I talked to the XMOS guys they told me about the programmable and > highly flexible IOs. That suggested somehow that you should not need an F= PGA > to glue the ADC to the XMOS chip. Can you tell us why this cannot be done= ? > > -Markus I don't think it's fast enough, I might try it though. I'll only need a small FPGA. LeonArticle: 136299
Hi there, I have a very stupid question. I was wondering how much silicon the actual FPGA logic (that is the slices and the BRAM ressources) are occuping on the physical chip. So can I expect that the whole physical chip is dedicated to these ressources or are there other components on the chip that take some space like flash memory for instance, or some other (external control) logic? Thanks, Max
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