Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Jun 14, 2:06=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > "newzhnd" <nob...@home.com> wrote in messagenews:XaeRn.26714$%u7.16071@ne= wsfe14.iad... > > Help !!! =A0 The megawizard in Quartus 2 does not seem to support gener= ating small roms & rams using > > the LUT > > tables, only using the M9K memory blocks. =A0Any way to generate small = roms & rams using the logic > > cells ? > > I'm looking for something similar to Xilinx distributed memory generato= r. > > Altera devices can't implement LUT based distributed memory, this is one = of > Xilinx's heavily patented uniqe selling points! > In fact Stratix3/4 and Aria2 support MLAB which is very similar to Xilinx distributed memory. So obviously they found a hole in Xilinx patent. > You just have to use device logic or M9Ks. For RAM on C2 - yes. Except, it's M4K rather than M9K As already mentioned here, even on C2 synthesis tools should be able to implement small ROM in LUTs. However, AFAIR, Quartus-II does not support initializing of such ROM from .mif or .hex file so every change of the ROM contest would require full recompilation. > > Nial.Article: 148026
According to the datasheet, The Spartan 6 family has Broad third-party SPI (up to x4) and NOR flash support Feature rich Xilinx Platform Flash with JTAG I don't quite understans if it supports NAND flash? I want to build and FPGA + ARM platform, each component has their own flash. How do you think, should I use just one NAND flash for both FPGA and processor access? Is NAND flash compatible with Xilinx Spartan 6? Anyone could help mepleas, Thank you. GladysArticle: 148027
Hi All I am designing a module and I am having some issues .. Let me explain what I am doing. I am getting data as 64 bytes in each clock cycle . In these 64 bytes I look for sync bits which is "01" and then a fixed pattern of "1111" for the start of the frame . The next byte tells us the length of the payload . Now the minimum payload could be of 4 byes so there is a chance that in the current 64 bytes we can have multiple short frames of 4 bytes and henceforth we can have many start and stop bytes . Once we have detected a sync and the start of frame pattern then we have to make sure it is not mistakingly taking the patter in the payload as the start of the frma e again . I have made a loop that goes 63 downto 0 and looks for each byte for sync and start bit pattern if it finds the sync and the start fame pattern then i am using a flag to make sure it is not mistakingly taking the pattern in the payload as the another start frame once it has detected the start of the frame and sync successfully. Solution : I have made a counter that runs inside the loop (63 down to 0) and it is 13 bits wide ( as there could be 8192 max payload) so once the count length is equal to payload length I am disabling the flag to allow it to go into detection of sync and start of the frame. Problem: The problem is that whe i am using a 13 bit counter inside a loop that goes 64 iterations makes a very large HW during syntheis . Can you provide a solution to this problem as i would be able to detect smallest payload ( 4 bytes in this case) as well as max payload bytes in an efficient way. I will really appreciate you help in this regard. Regards VipsArticle: 148028
Hi, Im working on communication for the Virtex 5 using Ethernet. As a good start, do you have any ideas/examples program which use Virtex5? I have tried browsing on the internet, but there are not much about Ethernet Virtex5 example codes. I would be very happy if somebody can guide to show a simple program to communicate using Ethernet-Virtex5. Cheers --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148029
Hi guys, When i try to simulate a simple EXOR i get the following error: # ** Warning: A ModelSim starter license was detected and will be used, even though you have installed ModelSim XE. You should obtain an XE license in order to access ModelSim XE's full capabilities.Licensing checkout error with feature xe-starter. (Error code -9.) # The hostid of the license does not match the hostid for this machine. # One of the following is likely: # -The license is intended for another machine. # -A dongle is not plugged into this machine. # -The dongle driver is not installed or is not functioning properly. # -The hostid mechanism has been changed or removed from this machine. # ** Error: Failure to obtain a VHDL simulation license. # Error loading design # Error: Error loading design # Pausing macro execution # MACRO ./my_exor_tb.fdo PAUSED at line 9 Can anyone help me??? Thanks all! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148030
Dear Friends,
i am using Altium Designer for fpga and embedded project on digilent
spartan3E-500 board.
I have created an FPGA project in Altium using open bus document containing
three device:
1. TSK3000A
2. WB_PRTIO_1 (for leds)
3. WB_UART_V2_1
Added a top level schematic sheet. Added constraint file to the project
containing correct fpga pin designators. Configured the TSK3000 memory size
as 16K. The fpga project gets synthesized and bit stream is generated
without any problem.
Next i created an embedded project and made it child of the TSK3000 cpu.
Configured Aplication Memory as 0-8K as ROM and 8k-16K as ram.
Adjusted the Stack size to 512. Heap size " " (nothing not even 0).
Created main.c and software platform document. My software platform
document contains:
hardware rappers:
1. WB_PRTIO_1
2. WB_UART_V2_1
and driver files:
1. DRV_PRTIO_1
2. DRV_UART_V2_1
following is my main.c:
-------------------------------------------------
#include <stdio.h>
#include <stdint.h>
#include <drv_uart8.h>
#include <drv_ioport.h>
#include "hardware.h"
#include "devices.h"
uart8_t* uart;
ioport_t* ioport;
void main(void)
{
int value=0;
uart = uart8_open(DRV_UART8_1); //uart8_t* uart8_open(int id);
uart8_set_baudrate(uart,19200);
ioport = ioport_open(DRV_IOPORT_1); //ioport_t* ioport_open(const int id);
value = uart8_write(uart,"helloworld\n", 20);
ioport_set_value(ioport, WB_PRTIO_1, 0xaa);
ioport_set_value(ioport, WB_PRTIO_1, 0x55);
while (1)
{
//int uart8_putchar(uart8_t *restrict drv, int val);
//uart8_putchar(uart, uart8_getchar(uart)); //int uart8_getchar(uart8_t
*restrict drv);
uart8_putchar(uart, 'U');
}
}
---------------------------------
I have attached pc com port with my boards serial port and running hyper
terminal on the other end of the serial cable.
Now the problem is:
I can write to leds without any problem but i never see prints from
uart8_write(); function.
I have following questions which I hope someone will come up with answers:
1. How to compute value of stack requirement?
2. How to compute value for heap?
3. What might be wrong with my design that i don't see message on the
serial port?
4. How can i configure my embedded design to re-direct printf output to
UART?
Regards.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 148031Hi all dear I have a DLC9G programmer for programming all FPGAs It was working good but from some days before I don't know why but after connecting programmer to board the LED is getting green but when I select Initialize chain in impact software I have an error that it says you don't have adequate voltage and some thing like this.please say to me what I should do. thanks alot --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148032
Symon wrote: > On 6/14/2010 1:45 PM, LC wrote: >> >> Should I expect that this would be the right up limit I could do it ? >> Is there any clever design of this frontend to allow higher speed ? >> > Does XAPP265 give you any architectural hints that you can use in your > Altera part? > HTH., Syms. Tks, Symon, Indeed there are some variations induced by this reading that I'll try. Thanks. Luis C.Article: 148033
On 15/06/2010 12:47, flipoo wrote: > Hi guys, > > When i try to simulate a simple EXOR i get the following error: > > # ** Warning: A ModelSim starter license was detected and will be used, > even though you have installed ModelSim XE. You should obtain an XE license > in order to access ModelSim XE's full capabilities.Licensing checkout error > with feature xe-starter. (Error code -9.) > # The hostid of the license does not match the hostid for this machine. > # One of the following is likely: > # -The license is intended for another machine. > # -A dongle is not plugged into this machine. > # -The dongle driver is not installed or is not functioning properly. > # -The hostid mechanism has been changed or removed from this machine. > # ** Error: Failure to obtain a VHDL simulation license. > # Error loading design > # Error: Error loading design > # Pausing macro execution > # MACRO ./my_exor_tb.fdo PAUSED at line 9 > > Can anyone help me??? > > Thanks all! > > > > > > --------------------------------------- > Posted through http://www.FPGARelated.com That seems pretty obvious, you haven't got a valid license. All the information you need is in the message you quoted. Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 148034
Nial Stewart wrote: > > As you're stepping through the 128 bits to extract the 16 bit output > I would have implemented it as a big shift register and take off the > top/bottom bits. > > Then all the tools have to worry about is a single register to register delay > rather than big mux required to 'select' the correct 16 bits. > > > Nial. > Nial, Ok, good idea. Tks, will try. Not sure what you mean by top/bottom but I presume it is something like having the long 1 bit 128bit SR with outputs at 0, 16, 32 etc while the parallel 128bit word has bit reordering such as each shift would produce the next 16bit word to come out. If I'm missing something let me know. Thanks. Luis C.Article: 148035
On Jun 15, 5:49=A0am, Gladys <yuhu...@gmail.com> wrote: > According to the datasheet, The Spartan 6 family has > > Broad third-party SPI (up to x4) and NOR flash support > Feature rich Xilinx Platform Flash with JTAG > > I don't quite understans if it supports NAND flash? > I want to build and FPGA + ARM platform, each component has their own > flash. > How do you think, should I use just one NAND flash for both FPGA and > processor access? > Is NAND flash compatible with Xilinx Spartan 6? > Anyone could help mepleas, Thank you. > > Gladys The point of SPI and NOR flash compatibility is that the FPGA is capable of configuring itself from these devices without any external glue logic required. It cannot do that with a NAND flash. The FPGA can certainly be programmed to use NAND flash for its storage requirements other than configuration. In that case you would still need some other device to configure the FPGA on power-up. Depending on the size of the non-configuration data required by the FPGA you may or may not want to hook it to the NAND flash if the processor has its own NAND flash interface. If the FPGA only needs a small amount of storage, you can use the same SPI flash that configures it, using the portion of the flash beyond the configuration bitstream. Regards, GaborArticle: 148036
On Jun 15, 6:55=A0am, Vips <thevipulsi...@gmail.com> wrote: > Hi All > > I am designing a module and I am having some issues .. Let me explain > what =A0I am doing. > > I am getting =A0data as 64 bytes in each clock cycle . In these 64 bytes > I look for sync bits which is "01" and then a fixed pattern of "1111" > for the start of the frame . The next byte tells us the length of the > payload . Now the minimum payload could be of 4 byes so there is a > chance that in the current 64 bytes we can have multiple short frames > of 4 bytes and henceforth we can have many start and stop bytes . > > Once we have detected a sync and the start of frame pattern then we > have to make sure it is not mistakingly taking the patter in the > payload as the start of the frma e again . > > I have made a loop that goes 63 downto 0 and looks for each byte for > sync and start bit pattern > > if it finds the sync and the start fame pattern then i am using a flag > to make sure it is not mistakingly taking the pattern in the payload > as the another start frame once it has detected the start of the frame > and sync successfully. > > Solution : I have made a counter that runs inside the loop (63 down to > 0) and it is 13 bits wide ( as there could be 8192 max payload) > > so once the count length is equal to payload length I am disabling the > flag to allow it to go into detection of sync and start of the frame. > > Problem: The problem is that whe i am using a 13 bit counter inside a > loop that goes 64 iterations makes a very large HW during syntheis . > > Can you provide a solution to this problem as i would be able to > detect smallest payload ( 4 bytes in this case) as well as max payload > bytes in an efficient way. > > I will really appreciate you help in this regard. > > Regards > > Vips It seems to me that you are trying to do an awful lot in one clock cycle. How fast is your clock? Can you run logic at many times the clock rate in order to serialize this task? I don't see how else to reduce the size of the hardware generated. Basically all of your loops are being unrolled to create hardware, so I'm not surprised that the HW is very large. Regards, GaborArticle: 148037
On Jun 15, 12:55=A0pm, Vips <thevipulsi...@gmail.com> wrote: > ... > Once we have detected a sync and the start of frame pattern then we > have to make sure it is not mistakingly taking the patter in the > payload as the start of the frma e again . > ... Hi, If you are designing the whole system (i.e. both sender and receiver)... what about using bit-stuffing ? Regards SandroArticle: 148038
Outline details and picture are now on http://www.enterpoint.co.uk/programming_solutions/prog4.html. John Adair Enterpoint Ltd. On 13 June, 14:15, John Adair <g...@enterpoint.co.uk> wrote: > In prep for the release of more Altera development board additions to > our range we have a new programming cable Prog4. We will be selling > this 2 ways. The first is as a programming cable and that will be in a > case similar to our Xilinx cable Prog3.. > > The second use is as a simple FT245 USB based development board where > in addition to the programming interfaces there are 36 I/O arranged in > our normal DIL Header configuration. That header can take things like > our 16 channel A/D modules or stripboard add ons. The board is based > on a XC3S50AN FPGA and will sell for GBP 50 approximately USD 75. > > Picture and more details will appear on website over the next 24 > hours. > > John Adair > Enterpoint Ltd.Article: 148039
Hi guys, I'm designing a PCB for a project of mine (a floppy disc data analyser -- see <http://www.discferret.com/>). This will be my first project with an FPGA, or at least the first one that's made it as far as actual PCBs being made. I'm using an Altera Cyclone II EP2C8 in TQ144 (144-pin TQFP) package. This has a 40MHz external clock (provided by a TTL oscillator module) which is multiplied up to 80MHz and down to 32MHz using the internal PLLs. There's an 8-bit multiplexed 10MByte/sec bus between the microcontroller (a Microchip PIC) and the FPGA. This bus has 8 data lines, an Address Latch line, and read and write control lines. Address data is sent by putting the address on the bus, strobing ALE, then data can be sent in the normal manner. I've got auto- incrementing address counters on the FPGA which reduce the time delays to a more sane degree. Everything is 3.3V LVTTL/LVCMOS, aside from the USB input to the PIC and the disc drive control lines (which are 5V open-collector at 1MHz max). No LVDS, LVPECL, ECL or anything like that. I/O routing is probably a non-issue at these frequencies; clock routing for the 40MHz master clock may be an issue -- it needs to come out of the TTL osc, then go to the CLKIN pin on the PIC and one of the GCK pins on the FPGA. Logic dictates that by putting the TTL module dead-centre between the PIC and the FPGA, I can keep clock skew to a minimum. Catch is, I'm not sure how that will affect the signal integrity. The board is double-sided, with the whole bottom layer dedicated to a ground plane (with the exception of one or two isolated tracks used to move things like VCC around). What I am worried about is decoupling. The old rule I used to hear banded about was "add a 0.1uF ceramic capacitor for every VCC/GND pair, and put it as near to that pair as you can, ideally within an inch". For the 2C8 alone, I'd be looking at 22 capacitors to find space for... Is 0.1uF the ideal value to use here, or would a 0.01uF work better? Can anyone offer some advice on the subject of decoupling? It seems it's a bit of a black art; the folks I've asked seem very reluctant to explain it (if they understand it themselves), and much of the reference material I've seen is either oversimplified or starts out simple and then turns into a horrendous equation-fest that would give a mathematician a migraine. I've also seem SMD ferrite beads -- typically 600 Ohms @ 100MHz -- used in series with the PSU, or as part of a "Pi" filter (inductor in series with power supply, capacitors to ground on both sides). Is there any advantage to adding these? (I know an EE who adds them to almost every power line -- his reason is "my university lecturer swears you need to do this, and they cost less than a penny each") Thanks, -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 148040
SI-LISTArticle: 148041
Philip It might be worth looking at this Xilinx applications note http://www.pa.msu.edu/hep/d0/ftp/run2b/l1cal/hardware/component_information/xilinx_xapp623_decoupling_caps.pdf. Very much the same goes for Altera. Some of the techniques are a bit extreme but worth a read never the less. A lot depends on layout whether it will work well. I have seen some customer projects have some real problems using a 2 layer approach. We have done 2 layer ourselves on our Polmaddie series of boards but these have relatively small devices fitted and that reduces the problem. Like you we have used the back layer as gnd and managed tracks and power on the other layer to achieve the low cost 2 layer structure. So far at least we have not seen any problems with these boards but I wouldn't use them for an application that was high performance. On capacitors I would use one per positive power pin as a practical number. John Adair Enterpoint Ltd. On 15 June, 22:32, Philip Pemberton <usene...@philpem.me.uk> wrote: > Hi guys, > I'm designing a PCB for a project of mine (a floppy disc data analyser -- > see <http://www.discferret.com/>). This will be my first project with an > FPGA, or at least the first one that's made it as far as actual PCBs > being made. > > I'm using an Altera Cyclone II EP2C8 in TQ144 (144-pin TQFP) package. > This has a 40MHz external clock (provided by a TTL oscillator module) > which is multiplied up to 80MHz and down to 32MHz using the internal PLLs. > There's an 8-bit multiplexed 10MByte/sec bus between the microcontroller > (a Microchip PIC) and the FPGA. > > This bus has 8 data lines, an Address Latch line, and read and write > control lines. Address data is sent by putting the address on the bus, > strobing ALE, then data can be sent in the normal manner. I've got auto- > incrementing address counters on the FPGA which reduce the time delays to > a more sane degree. > > Everything is 3.3V LVTTL/LVCMOS, aside from the USB input to the PIC and > the disc drive control lines (which are 5V open-collector at 1MHz max). > No LVDS, LVPECL, ECL or anything like that. > > I/O routing is probably a non-issue at these frequencies; clock routing > for the 40MHz master clock may be an issue -- it needs to come out of the > TTL osc, then go to the CLKIN pin on the PIC and one of the GCK pins on > the FPGA. Logic dictates that by putting the TTL module dead-centre > between the PIC and the FPGA, I can keep clock skew to a minimum. Catch > is, I'm not sure how that will affect the signal integrity. > > The board is double-sided, with the whole bottom layer dedicated to a > ground plane (with the exception of one or two isolated tracks used to > move things like VCC around). > > What I am worried about is decoupling. The old rule I used to hear banded > about was "add a 0.1uF ceramic capacitor for every VCC/GND pair, and put > it as near to that pair as you can, ideally within an inch". For the 2C8 > alone, I'd be looking at 22 capacitors to find space for... > Is 0.1uF the ideal value to use here, or would a 0.01uF work better? > > Can anyone offer some advice on the subject of decoupling? It seems it's > a bit of a black art; the folks I've asked seem very reluctant to explain > it (if they understand it themselves), and much of the reference material > I've seen is either oversimplified or starts out simple and then turns > into a horrendous equation-fest that would give a mathematician a > migraine. > > I've also seem SMD ferrite beads -- typically 600 Ohms @ 100MHz -- used > in series with the PSU, or as part of a "Pi" filter (inductor in series > with power supply, capacitors to ground on both sides). Is there any > advantage to adding these? > (I know an EE who adds them to almost every power line -- his reason is > "my university lecturer swears you need to do this, and they cost less > than a penny each") > > Thanks, > -- > Phil. > usene...@philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current yearArticle: 148042
On 15 Jun., 12:55, Vips <thevipulsi...@gmail.com> wrote: > Hi All > > I am designing a module and I am having some issues .. Let me explain > what =A0I am doing. > > I am getting =A0data as 64 bytes in each clock cycle . In these 64 bytes > I look for sync bits which is "01" and then a fixed pattern of "1111" > for the start of the frame . The next byte tells us the length of the > payload . Now the minimum payload could be of 4 byes so there is a > chance that in the current 64 bytes we can have multiple short frames > of 4 bytes and henceforth we can have many start and stop bytes . > > Once we have detected a sync and the start of frame pattern then we > have to make sure it is not mistakingly taking the patter in the > payload as the start of the frma e again . > > I have made a loop that goes 63 downto 0 and looks for each byte for > sync and start bit pattern > > if it finds the sync and the start fame pattern then i am using a flag > to make sure it is not mistakingly taking the pattern in the payload > as the another start frame once it has detected the start of the frame > and sync successfully. > > Solution : I have made a counter that runs inside the loop (63 down to > 0) and it is 13 bits wide ( as there could be 8192 max payload) > > so once the count length is equal to payload length I am disabling the > flag to allow it to go into detection of sync and start of the frame. > > Problem: The problem is that whe i am using a 13 bit counter inside a > loop that goes 64 iterations makes a very large HW during syntheis . > > Can you provide a solution to this problem as i would be able to > detect smallest payload ( 4 bytes in this case) as well as max payload > bytes in an efficient way. > > I will really appreciate you help in this regard. > > Regards > > Vips Hi Vips, did I get that right, that your sync word consists of 2+4=3D 6 Bits? Like Sandro said, things would be a lot easier if you could expand this to 8 bits, so you would be able to work on whole bytes only. Of course, to handle the data frames you need to do it at a higher clock rate than the data rate of your 64-Byte interface. How about this: Make your 64-Byte buffer a barrel shifter capable of moving the data by 1/4/8-Bit width. (This needs a 5-input LUT in front of each FF, actual FPGAs have 6-input LUTs and can do this at maximum clock speed) So you make a detection FSM at the end, that searches for '01'. If that is detected, a 4 bit comparator can tell you wether the following four bits are "1111" or not. If Not, you continue searching, if Yes you shift by 4 once to get rid of the "1111" nibble. Then you take the next byte to load your payload counter. (How can you have payloads between 4 and 8192 bytes with an 8 bit information? is it nonlinear?) Now you are moving the data by 8 bits at a time and forward it to the following stages until the end of the frame. You don't need a special flag, since everything is controlled by your FSM and the Frame Counter. After reading the last byte your FSM starts alll over again and searches for the next sync signal. The bad thing is that you have to search for a 2+4 bit pattern that can be anywhere in the 64 bit . This serial approach is nice, but needs high overclocking (in the worst case 512 times, but with some moderate use of combinatorical preprocessing, this may be reduced to 64 times). The problem is in the frame format, which doesn't fit into whole bytes. Do the 64 Bytes come from some deserializer? Why is the syncing not done on that level? It's low effort for a small FSM, so it could run on high frequencies. In that case you would just have a Frame Length byte at the beginning of your 64 byte buffer and need only 8 times overclocking and a bytewise-only barrel shifter, which is simple. All the junk data and sync bits have already been thrown out. I hope there have been some helpful suggestions for your problem. Have a nice synthesis EilertArticle: 148043
> Ok, good idea. Tks, will try.
> Not sure what you mean by top/bottom but I presume it is something like
> having the long 1 bit 128bit SR with outputs at 0, 16, 32 etc while the parallel 128bit word has
> bit reordering such as each shift would produce the next 16bit word to come out. If I'm missing
> something let me know.
Something like this, with a load value....
signal shift_reg : std_logic_vector(127 downto 0);
signal output : std_logic_vector(15 downto 0);
signal load_value : std_logic_vector(127 downto 0);
:
:
:
process(clk,rst)
begin
if(rst = '1') then
shift_reg <= (others => '0');
output <= (others => '0');
elsif(rising_edge(clk)) then
if(load = '1') then
shift_reg <= load_value;
else
shift_reg(127 downto 112) <= shift_reg(111 downto 96;
shift_reg(111 downto 96) <= shift_reg(95 downto 80);
shift_reg(79 downto 64) <= shift_reg(63 downto 48);
:
:
shift_reg(31 downto 16) <= shift_reg(15 downto 0);
end if;
output <= shift_reg(127 downto 112);
end if;
end process;
Nial
Article: 148044This is a cost/time/risk trade-off. How many do you expect to make? 10? 1000? million? The more you make, the more worthwhile it is trying to reduce the number of ancilliary components. http://en.wikipedia.org/wiki/Madman_Muntz If you intend to make only 1 batch, ensure that the PCB part of the design works properly, unless you like wasting time+money. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 148045
Nial Stewart wrote: >> Ok, good idea. Tks, will try. >> Not sure what you mean by top/bottom but I presume it is something like >> having the long 1 bit 128bit SR with outputs at 0, 16, 32 etc while the parallel 128bit word has >> bit reordering such as each shift would produce the next 16bit word to come out. If I'm missing >> something let me know. > > Something like this, with a load value.... > > signal shift_reg : std_logic_vector(127 downto 0); > signal output : std_logic_vector(15 downto 0); > signal load_value : std_logic_vector(127 downto 0); > > > : > : > : > > process(clk,rst) > begin > if(rst = '1') then > shift_reg <= (others => '0'); > output <= (others => '0'); > elsif(rising_edge(clk)) then > if(load = '1') then > shift_reg <= load_value; > else > shift_reg(127 downto 112) <= shift_reg(111 downto 96; > shift_reg(111 downto 96) <= shift_reg(95 downto 80); > shift_reg(79 downto 64) <= shift_reg(63 downto 48); > : > : > shift_reg(31 downto 16) <= shift_reg(15 downto 0); > > end if; > > output <= shift_reg(127 downto 112); > > end if; > end process; > > > Nial > > Thanks for the clarification. Yes, Now I've tested both: the 1 bit SR with 128 with bit reordering on both sides (which is just messing up with the bit order must not consume precious time) And the SR in 16bit chunks approach you suggested. Both resulted identical (as expected... they are after all not too different if we think of the data path delay). Both were indeed a bit faster than my previous counter/mux approach. Now I'm closer to 400MHz... I believe that is what I could do with this technology. Again, tks, Luis C.Article: 148046
On 6/15/2010 12:57 PM, LC wrote: > Symon wrote: >> On 6/14/2010 1:45 PM, LC wrote: >>> >>> Should I expect that this would be the right up limit I could do it ? >>> Is there any clever design of this frontend to allow higher speed ? >>> >> Does XAPP265 give you any architectural hints that you can use in your >> Altera part? >> HTH., Syms. > > Tks, Symon, > Indeed there are some variations induced by this reading that I'll try. > Thanks. > > Luis C. Hi Luis, You might want to pay particular attention to the DDR registers in the IOBs. I expect your Altera part has the same features, but I dunno for sure. The registers mean that your internal logic can run at half the speed of the external signals. Which is nice. HTH, Syms.Article: 148047
On Jun 16, 9:03=A0am, backhus <goous...@googlemail.com> wrote: > ... > did I get that right, that your sync word consists of 2+4=3D 6 Bits? > Like Sandro said, things would be a lot easier if you could expand > this to 8 bits, so you would be able to work on whole bytes only. > Of course, to handle the data frames you need to do it at a higher > clock rate than the data rate of your 64-Byte interface. > ... I should be more clear... I don't mean to bring 2+4=3D6 bits to 8 bits. I mean to use a bit-stuffer on the transmit module (just before the "framer") in order to completely avoid the sync and/or start sequence to be present in the payload and a bit-destuffer on the receiver side just after the "deframer"... Regards SandroArticle: 148048
On Jun 16, 12:03=A0pm, backhus <goous...@googlemail.com> wrote: > On 15 Jun., 12:55, Vips <thevipulsi...@gmail.com> wrote: > > > > > Hi All > > > I am designing a module and I am having some issues .. Let me explain > > what =A0I am doing. > > > I am getting =A0data as 64 bytes in each clock cycle . In these 64 byte= s > > I look for sync bits which is "01" and then a fixed pattern of "1111" > > for the start of the frame . The next byte tells us the length of the > > payload . Now the minimum payload could be of 4 byes so there is a > > chance that in the current 64 bytes we can have multiple short frames > > of 4 bytes and henceforth we can have many start and stop bytes . > > > Once we have detected a sync and the start of frame pattern then we > > have to make sure it is not mistakingly taking the patter in the > > payload as the start of the frma e again . > > > I have made a loop that goes 63 downto 0 and looks for each byte for > > sync and start bit pattern > > > if it finds the sync and the start fame pattern then i am using a flag > > to make sure it is not mistakingly taking the pattern in the payload > > as the another start frame once it has detected the start of the frame > > and sync successfully. > > > Solution : I have made a counter that runs inside the loop (63 down to > > 0) and it is 13 bits wide ( as there could be 8192 max payload) > > > so once the count length is equal to payload length I am disabling the > > flag to allow it to go into detection of sync and start of the frame. > > > Problem: The problem is that whe i am using a 13 bit counter inside a > > loop that goes 64 iterations makes a very large HW during syntheis . > > > Can you provide a solution to this problem as i would be able to > > detect smallest payload ( 4 bytes in this case) as well as max payload > > bytes in an efficient way. > > > I will really appreciate you help in this regard. > > > Regards > > > Vips > > Hi Vips, > did I get that right, that your sync word consists of 2+4=3D 6 Bits? > Like Sandro said, things would be a lot easier if you could expand > this to 8 bits, so you would be able to work on whole bytes only. > Of course, to handle the data frames you need to do it at a higher > clock rate than the data rate of your 64-Byte interface. > > How about this: > Make your 64-Byte buffer a barrel shifter capable of moving the data > by 1/4/8-Bit width. (This needs a 5-input LUT in front of each FF, > actual FPGAs have 6-input LUTs and can do this at maximum clock speed) > So you make a detection FSM at the end, that searches for =A0'01'. If > that is detected, a 4 bit comparator can tell you wether the following > four bits are "1111" or not. > If Not, you continue searching, if Yes you shift by 4 once to get rid > of the "1111" nibble. > Then you take the next byte to load your payload counter. (How can you > have payloads between 4 and 8192 bytes with an 8 bit information? is > it nonlinear?) > Now you are moving the data by 8 bits at a time and forward it to the > following stages until the end of the frame. > You don't need a special flag, since everything is controlled by your > FSM and the Frame Counter. > After reading the last byte your FSM starts alll over again and > searches for the next sync signal. > > The bad thing is that you have to search for a 2+4 bit pattern that > can be anywhere in the 64 bit . > This serial approach is nice, but needs high overclocking (in the > worst case 512 times, but with some moderate use of combinatorical > preprocessing, this may be reduced to 64 times). > > The problem is in the frame format, which doesn't fit into whole > bytes. > Do the 64 Bytes come from some deserializer? > Why is the syncing not done on that level? It's low effort for a small > FSM, so it could run on high frequencies. > In that case you would just have a Frame Length byte at the beginning > of your 64 byte buffer and need only 8 times overclocking and a > bytewise-only barrel shifter, which is simple. > All the junk data and sync bits have already been thrown out. > > I hope there have been some helpful suggestions for your problem. > Have a nice synthesis > =A0 Eilert Hi Eilert /Sandro Thanks for the suggestion. I would like to slightly modify the spec here , may be i did not made clear. I have made a record and date is separate with includes the frame pattern "1111" other 4+ 8 is the length. The sync bit is separately moved in record so i just try to see the sync bits "01" in the recored. I am getting the frame in the form of record that has (4+ 8) array of 64 values. I have no choice as i am getting the record type as input so i have to process it the way i am getting it. Again if i do sequential search then i will have to use a loop to detect the sync and the frame start pattern thanks vipulArticle: 148049
On Jun 15, 5:32=A0pm, Philip Pemberton <usene...@philpem.me.uk> wrote: > Hi guys, > I'm designing a PCB for a project of mine (a floppy disc data analyser -- > see <http://www.discferret.com/>). This will be my first project with an > FPGA, or at least the first one that's made it as far as actual PCBs > being made. > > I'm using an Altera Cyclone II EP2C8 in TQ144 (144-pin TQFP) package. > This has a 40MHz external clock (provided by a TTL oscillator module) > which is multiplied up to 80MHz and down to 32MHz using the internal PLLs= . > There's an 8-bit multiplexed 10MByte/sec bus between the microcontroller > (a Microchip PIC) and the FPGA. > > This bus has 8 data lines, an Address Latch line, and read and write > control lines. Address data is sent by putting the address on the bus, > strobing ALE, then data can be sent in the normal manner. I've got auto- > incrementing address counters on the FPGA which reduce the time delays to > a more sane degree. > > Everything is 3.3V LVTTL/LVCMOS, aside from the USB input to the PIC and > the disc drive control lines (which are 5V open-collector at 1MHz max). > No LVDS, LVPECL, ECL or anything like that. > > I/O routing is probably a non-issue at these frequencies; clock routing > for the 40MHz master clock may be an issue -- it needs to come out of the > TTL osc, then go to the CLKIN pin on the PIC and one of the GCK pins on > the FPGA. Logic dictates that by putting the TTL module dead-centre > between the PIC and the FPGA, I can keep clock skew to a minimum. Catch > is, I'm not sure how that will affect the signal integrity. > > The board is double-sided, with the whole bottom layer dedicated to a > ground plane (with the exception of one or two isolated tracks used to > move things like VCC around). > > What I am worried about is decoupling. The old rule I used to hear banded > about was "add a 0.1uF ceramic capacitor for every VCC/GND pair, and put > it as near to that pair as you can, ideally within an inch". For the 2C8 > alone, I'd be looking at 22 capacitors to find space for... > Is 0.1uF the ideal value to use here, or would a 0.01uF work better? > > Can anyone offer some advice on the subject of decoupling? It seems it's > a bit of a black art; the folks I've asked seem very reluctant to explain > it (if they understand it themselves), and much of the reference material > I've seen is either oversimplified or starts out simple and then turns > into a horrendous equation-fest that would give a mathematician a > migraine. > > I've also seem SMD ferrite beads -- typically 600 Ohms @ 100MHz -- used > in series with the PSU, or as part of a "Pi" filter (inductor in series > with power supply, capacitors to ground on both sides). Is there any > advantage to adding these? > (I know an EE who adds them to almost every power line -- his reason is > "my university lecturer swears you need to do this, and they cost less > than a penny each") > > Thanks, > -- > Phil. > usene...@philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current yea= r "Finding space for" capacitors really depends on the package. You can get 0.1uF in an 0402 package that almost aligns with adjacent pads of your TQ144 package. I normally don't add the ferrites except for supplies that really need to be quiet. I'm not that familiar with Altera parts, but for Xilinx parts I only use ferrites in the lines supplying transceiver power. If your part has a separate power pin for PLL's for example you might want to use ferrites there. Also don't forget the bulk decoupling, especially on the internal Vcc supply where a large portion of the power draw is dynamic. I've had large designs fail due to insufficent bulk capacitance, and it's a real pain to find a place to tack a 1206 sized cap on after the fact. Good luck on your project, Gabor
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