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
Ed McGettigan wrote: > I noticed that the PCB connector isn't keyed in any manner > which can lead to some nasty problems with inexperienced users. or tired, exhausted, sleep-deprived developers. don't ask me why... > Ed McGettigan > -- > Xilinx Inc. yg -- http://ygdes.com / http://yasep.orgArticle: 147701
On May 17, 12:58=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > It could start to affect device selection. > > Are you serious? > > Well, probably not. > > > I don't think that Xilinx, Altera or ARM really care what header is > > used on the target board. =A0Each of use picked something that we think > > makes sense and provided a ribbon cable that mates the JTAG cable to > > the target board. > > It did make sense 15 years ago, but it's a bit ridiculous if you're using > 0201/0402 components to have to use the behemoth 2x5 0.1" pin header. > > :-) > > > Nothing prevents you from using an alternative connector on the target > > board and creating an adapter that connects to the JTAG cable. > > Adaptors lead to un-reliability, wires getting crossed or shorted etc. > It would be nice to have a more compact 'standard'. > > The EEBlaster that Thomas linked to earlier in the thread... > > http://www.entner-electronics.com/tl/index.php/eeblaster.html > > ...has two 'programming heads' which seems a good solution. > > Nial. Xilinx used a 1x7 0.1" header with flying leads in the past, but now uses a 2x7 2mm header (one side is all GND for shielding). If the adapter is a very simple 2-layer PCB that converts the JTAG cable connector to your favorite connector then there wouldn't be reliability problems. I can't tell from the EEBlaster picture if the two ribbon cables are permanently connected to the box or not. If they are then I would be worried about the signal integrity of the interface due to the large stub from the unused cable. They list as one of the features "improved signal integrity" so maybe they had some problems with this in the past. I noticed that the PCB connector isn't keyed in any manner which can lead to some nasty problems with inexperienced users. There are many ways to implement this simple function and regardless of what Xilinx, Altera or ARM does in this area someone won't be happy. For the foreseeable future, Xilinx will be sticking with the 2x7 2mm connector. Feel free to use it if meets your needs, if it doesn't then and adapters are simple and easy to create. Ed McGettigan -- Xilinx Inc.Article: 147702
> But, is there a way to debug a hardware design that is not made on FPGA, > using FPGA's ChipScope tool? > If you create a design on a Xilinx FPGA where the signals wired to the ChipScope are fed by external signals and add some trigger logic and clocks I don't see what can stop you. Maybe just the availability of better and cheaper dedicated solutions. -Alex. --- news://freenews.netfront.net/ - complaints: news@netfront.net ---Article: 147703
On May 16, 11:07=A0am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote:
> Am 13.05.2010 16:18, schrieb John McCaskill:
>
> > The problem is this bit of code:
>
> > process (Inc_cnt, Dec_cnt)
> > begin
> > =A0 if Inc_cnt =3D '1' then
> > =A0 =A0 Int_count <=3D Int_count + 1;
> > =A0 elsif Dec_cnt =3D '1' then
> > =A0 =A0 Int_count <=3D Int_count - 1;
> > =A0 end if;
>
> > end process;
>
> > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the
> > clock.
>
> You pointed out a very bad piece of code, but it is not a flipflop - it
> is a latch as rickman has already pointed out.
>
> It has 2 big design errors:
>
> 1) muxed latch: Inc_cnt and Dec_cnt drive latch-enable and mux-select.
> This is very bad design because no one can say if the latch-enable or
> the mux-select chances first in the moment when Inc_cnt / Dec_cnt become
> inactive.
>
> 2) infinite loop: As long as Inc_cnt / Dec_cnt is enable, Int_count is
> incremented / decremented. During simulation this problem did not show
> up, because the sensitivity list of this process is incomplete. Put
> Int_count into the sensitivity list and the simulator will freeze forever=
.
>
> Ralf
I have rewritten the bad piece of code, but still a latch is
synthesized for Int_count signal. Can anybody tell what is wrong with
this piece of code ?
process (Inc_cnt, Dec_cnt, RST)
begin
if RST =3D '0' then
Int_count <=3D (others =3D> '0');
elsif Inc_cnt =3D '1' then
Int_count <=3D Int_count + 1;
elsif Dec_cnt =3D '1' then
Int_count <=3D Int_count - 1;
else
Int_count <=3D Int_count + 0; -- I want to do a "no operation" here.
end if;
end process;
Article: 147704On Mon, 17 May 2010 22:32:15 -0700 (PDT), Sharath Raju <brsharath@gmail.com> wrote: >I have rewritten the bad piece of code, but still a latch is >synthesized for Int_count signal. Can anybody tell what is wrong with >this piece of code ? > >process (Inc_cnt, Dec_cnt, RST) >begin > if RST = '0' then > Int_count <= (others => '0'); > elsif Inc_cnt = '1' then > Int_count <= Int_count + 1; > elsif Dec_cnt = '1' then > Int_count <= Int_count - 1; > else > Int_count <= Int_count + 0; -- I want to do a "no operation" here. > end if; > >end process; There is nothing wrong with the code. The problem lies with your conflicting requirements. You want Int_count to remember its last state if there is no reason to assign to it; saying 'else foo = foo' is the same as leaving else out. This requires storage or memory. If you want int_count to remember its last value when you do no operation, you can't avoid a latch or a flip-flop os some other storage/memory. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147705
Roger It's easy to do if you have a FPGA of a board that has lots of I/O free and accessable. A number of our customers use our Darnaw1 FPGA module http://www.enterpoint.co.uk/moelbryn/darnaw1.html to do just than because it has a large I/O count. Basically this module is turned into logic analyser head with a simple design with inputs fed to a Chipscope core. When doing this it is important to use I/O registers to avoid timing skew and distortion. Accuracy is related to the sample clock that you use. Usually the onboard oscillator of the Darnaw1 is multiplied up by a DCM within the Spartan-3E FPGA to get something like a 100-200 MHz sample clock. The remaining problem is the flying wires or if planned a socket on your board. For flying wires keep these of equal length and if possible use a screened cable. John Adair Enterpoint Ltd. - Home of Darnaw1. The PGA FPGA Module. On 17 May, 13:07, "roger" <educationale@n_o_s_p_a_m.yahoo.com> wrote: > Hello, > > I am new to FPGA debugging using ChipScope. > > I know that ChipScope Pro tool is an internal logic analyser for FPGA > Hardware designs.... > > But, is there a way to debug a hardware design that is not made on FPGA, > using FPGA's ChipScope tool? > > Thanks for your help! > > Roger > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 147706
On May 17, 3:17=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On May 17, 1:49=A0am, "Nial Stewart" > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > >> Come on Altera (and the rest), give us a standard. > > > don't count on them to "give" a "good" standard ;-) > > > they're in for the money, they follow the money... > > > Aye, but it's getting to the stage where an FPGA and programming > > memory footprint is matched by the programming header! > > > It could start to affect device selection. > > Are you serious? > > I don't think that Xilinx, Altera or ARM really care what header is > used on the target board. =A0Each of use picked something that we think > makes sense and provided a ribbon cable that mates the JTAG cable to > the target board. > > Nothing prevents you from using an alternative connector on the target > board and creating an adapter that connects to the JTAG cable. > > Ed McGettigan > -- > Xilinx Inc. Yes, I have seen that done, but it is often a PITA to come up with the adapter cable. Going from a 0.1" connector to a 2 mm connector is not really a big advantage, especially when the problem is connector height. The best connector is a two piece design like the Conan series from FCI or similar. The pins are fully supported by the housing and so are not delicate, they have a small footprint, they are cheap, but most of all, they can be very, very short, even when mated to the cable. The only down side is that they are not so easy to use if not supported as a standard. Ideally the cable would be a flex cable. That costs a lot to make in small quantity. If the FPGA vendors used a common connector the flex cable and connector could be a standard programmer component. I guess I don't agree with your other post that adapters are "simple and easy" to make. I guess they are if you are just going from one large connector to another large connector. But then, what is the point? Is this an example of vendors listening to their customers? RickArticle: 147707
Hi, I am about to design a packetizer logic to interface to Xilinx's Aurora Core. I will be using Virtex5 SX95. I have worked with Virtex2Pro MGTs before, but this is my first time working on Aurora and the GTX interfaces. And also this is my first time designing packetised/framed interfaces. I was reading the aurora_8b10b_ug353.pdf. And in the user interace section, there are two options, there is Framing and Streaming interface. Am I correct in thinking that Framing interface will be best to connect to my Packetizer interface? Any other thoughts on this is highly appreciated. Thanks Binu --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147708
> I can't tell from the EEBlaster picture if the two ribbon cables are > permanently connected to the box or not. =A0If they are then I would be > worried about the signal integrity of the interface due to the large > stub from the unused cable. The stub does not cause problems with signal integrity. When in doubt, it is easy to remove (unplug) each of the cables by opening the housing with one screw. > They list as one of the features "improved > signal integrity" so maybe they had some problems with this in the > past. The "improved" is compared to other solutions, not to a previous version ;-) > I noticed that the PCB connector isn't keyed in any manner > which can lead to some nasty problems with inexperienced users. In fact, when you use a walled header, it is keyed. However, it is intended to be used with unwalled headers (for the smaller size) and there will be no problems for all common false connectings. With the red "Target"-LED you can immediately see if it is pluged in correctly, when the target is powered. Regards, ThomasArticle: 147709
Hi, I´m using MIG v3.0 to generate the VHDL code for a DDR SDRAM controller. I implement the design but I don´t know which is the format(values) the inputs signal, as for example app_af_addr, app_mask_data and app_wdf_data. And where do I declare the signals? Thanks a lot in advance. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147710
On May 17, 11:47=A0pm, rickman <gnu...@gmail.com> wrote: > On May 17, 3:17=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On May 17, 1:49=A0am, "Nial Stewart" > > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > >> Come on Altera (and the rest), give us a standard. > > > > don't count on them to "give" a "good" standard ;-) > > > > they're in for the money, they follow the money... > > > > Aye, but it's getting to the stage where an FPGA and programming > > > memory footprint is matched by the programming header! > > > > It could start to affect device selection. > > > Are you serious? > > > I don't think that Xilinx, Altera or ARM really care what header is > > used on the target board. =A0Each of use picked something that we think > > makes sense and provided a ribbon cable that mates the JTAG cable to > > the target board. > > > Nothing prevents you from using an alternative connector on the target > > board and creating an adapter that connects to the JTAG cable. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Yes, I have seen that done, but it is often a PITA to come up with the > adapter cable. =A0Going from a 0.1" connector to a 2 mm connector is not > really a big advantage, especially when the problem is connector > height. =A0The best connector is a two piece design like the Conan > series from FCI or similar. =A0The pins are fully supported by the > housing and so are not delicate, they have a small footprint, they are > cheap, but most of all, they can be very, very short, even when mated > to the cable. =A0The only down side is that they are not so easy to use > if not supported as a standard. =A0Ideally the cable would be a flex > cable. =A0That costs a lot to make in small quantity. =A0If the FPGA > vendors used a common connector the flex cable and connector could be > a standard programmer component. > > I guess I don't agree with your other post that adapters are "simple > and easy" to make. =A0I guess they are if you are just going from one > large connector to another large connector. =A0But then, what is the > point? > > Is this an example of vendors listening to their customers? > > Rick- Hide quoted text - > > - Show quoted text - When I said that adapters are simple, this is an example of what I talking about. http://farm3.static.flickr.com/2598/4167273762_609f88c0e1_o.jpg This converted from the Xilinx 2x7 2mm header to the previous flying wire style. Doing the same for another connector would not involve creating a custom cable with two different connectors. The simple PCB adapter would have the Xilinx/Altera/ARM connector on one side and your favorite connector mate on the other. The ribbon/flex cable would have your favorite connector on both ends and would likely be a standard product if you are using a popular connector. > Is this an example of vendors listening to their customers? We listen all of the time, but we often hear mutually exclusive desires. There was a big uproar when we went from the 1x7 100mil flying lead style to current 2x7 2mm header. In order to ease the transition the adapter above was created. Ed McGettigan -- Xilinx Inc.Article: 147711
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> writes: >> The point is that those assignments *are* used in synthesis by some >> tools. XST does it for one. It makes no sense for an ASIC, but for >> FPGAs which have a well defined startup condition defined by the >> bitstream it makes eminent sense. >> >> Now whether you want to take advantage of it depends on how portable >> to ASIC you want your code to be > > > Or whether you want to have completely unpredictable/broken behaviour > if you decide to change FPGA vendors! > Is it *that* bad across FPGA families? Xilinx and Altera (IIRC) both support initialisation for registers, Lattice use Synplify, which also supports it - so that's the vast majority of the FPGA market covered. It's only if you change to something very niche that it might fall apart. But that's the nature of engineering - sometimes you use something unportable because it gets you where you need to be now. Or you know where you're never going to have to go. You don't do it more than is absolutely necessary, and if you're bright you do it in a way that keeps it isolated so it's easy to swap something else in if it becomes necessary. So far I've only needed it for the reset synchroniser anyway... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 147712
On May 18, 11:59=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On May 17, 11:47=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On May 17, 3:17=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On May 17, 1:49=A0am, "Nial Stewart" > > > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > > >> Come on Altera (and the rest), give us a standard. > > > > > don't count on them to "give" a "good" standard ;-) > > > > > they're in for the money, they follow the money... > > > > > Aye, but it's getting to the stage where an FPGA and programming > > > > memory footprint is matched by the programming header! > > > > > It could start to affect device selection. > > > > Are you serious? > > > > I don't think that Xilinx, Altera or ARM really care what header is > > > used on the target board. =A0Each of use picked something that we thi= nk > > > makes sense and provided a ribbon cable that mates the JTAG cable to > > > the target board. > > > > Nothing prevents you from using an alternative connector on the targe= t > > > board and creating an adapter that connects to the JTAG cable. > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Yes, I have seen that done, but it is often a PITA to come up with the > > adapter cable. =A0Going from a 0.1" connector to a 2 mm connector is no= t > > really a big advantage, especially when the problem is connector > > height. =A0The best connector is a two piece design like the Conan > > series from FCI or similar. =A0The pins are fully supported by the > > housing and so are not delicate, they have a small footprint, they are > > cheap, but most of all, they can be very, very short, even when mated > > to the cable. =A0The only down side is that they are not so easy to use > > if not supported as a standard. =A0Ideally the cable would be a flex > > cable. =A0That costs a lot to make in small quantity. =A0If the FPGA > > vendors used a common connector the flex cable and connector could be > > a standard programmer component. > > > I guess I don't agree with your other post that adapters are "simple > > and easy" to make. =A0I guess they are if you are just going from one > > large connector to another large connector. =A0But then, what is the > > point? > > > Is this an example of vendors listening to their customers? > > > Rick- Hide quoted text - > > > - Show quoted text - > > When I said that adapters are simple, this is an example of what I > talking about.http://farm3.static.flickr.com/2598/4167273762_609f88c0e1_o= .jpg > > This converted from the Xilinx 2x7 2mm header to the previous flying > wire style. Doing the same for another connector would not involve > creating a custom cable with two different connectors. The simple PCB > adapter would have the Xilinx/Altera/ARM connector on one side and > your favorite connector mate on the other. The ribbon/flex cable would > have your favorite connector on both ends and would likely be a > standard product if you are using a popular connector. I'm not sure what you are saying exactly, but it sounds like you are suggesting that I make my own custom cable adapter which is exactly what I am saying is the problem. The image you provide shows a large bulky header/pcb/header which is exactly what I am saying is a very poor solution in many applications. If I need to test a board in a stack that only has 5 mm clearance between boards, how am I supposed to get that monster in there? > > Is this an example of vendors listening to their customers? > > We listen all of the time, but we often hear mutually exclusive > desires. =A0There was a big uproar when we went from the 1x7 100mil > flying lead style to current 2x7 2mm header. =A0In order to ease the > transition the adapter above was created. It would seem to me that Xilinx did a "Classic Coke" change where the customers weren't allowed a choice until they yelled. Sure, if you change your programming cables to drop compatibility with the existing way of connecting, there will be plenty of people who will yell. The product mentioned above is a good example of how to offer an improvement and maintain compatibility. It's only a shame that they didn't go to a low profile connector. There are a lot of apps for low profile devices. Just look at your packaging. How do people debug those designs with a debugging header that is > 10 mm tall? I have used custom approaches (at other companies) when the vendor approaches didn't work. But for a one off, this is an expensive way to go. RickArticle: 147713
On May 14, 8:54=A0pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > "Thomas Entner" <thomas.ent...@entner-electronics.com> wrote in message > > news:25e512b7-8076-495a-b1ee-95e080e01ff5@k17g2000yqf.googlegroups.com... > > > With our EEBlaster (http://www.entner-electronics.com/tl/index.php/ > > eeblaster.html), we support a 2x3 2mm pitch header which uses just > > about 1/3 of the area of the 2x5 header. We think this is a good > > compromise of size, price, reliability and availability. We have the > > pinout made public on the mentioned link, so everyone can use it, > > either together with our EEBlaster or with a self-made adapter-cable. > > Best regards > > Thomas Entner > >www.entner-electronics.com > > That certainly looks a good option Thomas, top of the contenders so far! > > Nial. 2mm pitch is a good size/strength/standard compromise, but I'd not stop at 2x3/2mm; such a standard, should have more than one size, the others being super-sets. So the minimum common subset, is 2x3, then you add another 2x3 for example, to allow more test signals. With FT2232 and FT2232H becoming standard, there are a lot of unused (but paid for) signals sitting right next to the JTAG ones. Then you cover not just JTAG, but also a reasonable amount of PCB run- time-test as well. -jgArticle: 147714
"aleksa" <aleksazr@gmail.com> wrote in message news:hsofgj$mrk$1@news.eternal-september.org... > Spartan 2 docs clearly says that, even though > you are configuring the FPGA in serial mode, > you should keep CS pin high. > > What about Spartan 3? > > I don't see something like: > "Yes, Spartan 2 had an error, but it has been fixed in Spartan 3" > > OK, when I build my board, I will toggle CS pin (with active WR) during serial config and will write here.Article: 147715
On May 18, 10:45=A0am, rickman <gnu...@gmail.com> wrote: > On May 18, 11:59=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On May 17, 11:47=A0pm, rickman <gnu...@gmail.com> wrote: > > > > On May 17, 3:17=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > On May 17, 1:49=A0am, "Nial Stewart" > > > > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > > > > >> Come on Altera (and the rest), give us a standard. > > > > > > don't count on them to "give" a "good" standard ;-) > > > > > > they're in for the money, they follow the money... > > > > > > Aye, but it's getting to the stage where an FPGA and programming > > > > > memory footprint is matched by the programming header! > > > > > > It could start to affect device selection. > > > > > Are you serious? > > > > > I don't think that Xilinx, Altera or ARM really care what header is > > > > used on the target board. =A0Each of use picked something that we t= hink > > > > makes sense and provided a ribbon cable that mates the JTAG cable t= o > > > > the target board. > > > > > Nothing prevents you from using an alternative connector on the tar= get > > > > board and creating an adapter that connects to the JTAG cable. > > > > > Ed McGettigan > > > > -- > > > > Xilinx Inc. > > > > Yes, I have seen that done, but it is often a PITA to come up with th= e > > > adapter cable. =A0Going from a 0.1" connector to a 2 mm connector is = not > > > really a big advantage, especially when the problem is connector > > > height. =A0The best connector is a two piece design like the Conan > > > series from FCI or similar. =A0The pins are fully supported by the > > > housing and so are not delicate, they have a small footprint, they ar= e > > > cheap, but most of all, they can be very, very short, even when mated > > > to the cable. =A0The only down side is that they are not so easy to u= se > > > if not supported as a standard. =A0Ideally the cable would be a flex > > > cable. =A0That costs a lot to make in small quantity. =A0If the FPGA > > > vendors used a common connector the flex cable and connector could be > > > a standard programmer component. > > > > I guess I don't agree with your other post that adapters are "simple > > > and easy" to make. =A0I guess they are if you are just going from one > > > large connector to another large connector. =A0But then, what is the > > > point? > > > > Is this an example of vendors listening to their customers? > > > > Rick- Hide quoted text - > > > > - Show quoted text - > > > When I said that adapters are simple, this is an example of what I > > talking about.http://farm3.static.flickr.com/2598/4167273762_609f88c0e1= _o.jpg > > > This converted from the Xilinx 2x7 2mm header to the previous flying > > wire style. Doing the same for another connector would not involve > > creating a custom cable with two different connectors. The simple PCB > > adapter would have the Xilinx/Altera/ARM connector on one side and > > your favorite connector mate on the other. The ribbon/flex cable would > > have your favorite connector on both ends and would likely be a > > standard product if you are using a popular connector. > > I'm not sure what you are saying exactly, but it sounds like you are > suggesting that I make my own custom cable adapter which is exactly > what I am saying is the problem. =A0The image you provide shows a large > bulky header/pcb/header which is exactly what I am saying is a very > poor solution in many applications. =A0If I need to test a board in a > stack that only has 5 mm clearance between boards, how am I supposed > to get that monster in there? > > > > Is this an example of vendors listening to their customers? > > > We listen all of the time, but we often hear mutually exclusive > > desires. =A0There was a big uproar when we went from the 1x7 100mil > > flying lead style to current 2x7 2mm header. =A0In order to ease the > > transition the adapter above was created. > > It would seem to me that Xilinx did a "Classic Coke" change where the > customers weren't allowed a choice until they yelled. =A0Sure, if you > change your programming cables to drop compatibility with the existing > way of connecting, there will be plenty of people who will yell. =A0The > product mentioned above is a good example of how to offer an > improvement and maintain compatibility. =A0It's only a shame that they > didn't go to a low profile connector. > > There are a lot of apps for low profile devices. =A0Just look at your > packaging. =A0How do people debug those designs with a debugging header > that is > 10 mm tall? =A0I have used custom approaches (at other > companies) when the vendor approaches didn't work. =A0But for a one off, > this is an expensive way to go. > > Rick- Hide quoted text - > > - Show quoted text - You don't put the adapter on your PCB board, it goes on the cable pod. Xilinx didn't wait until people complained. We knew that it would be an issue and the adapter was included in the initial PC-IV and USB cables to support legacy systems. Ed McGettigan -- Xilinx Inc.Article: 147716
Have you tried just creating a 24 bit accumulator, without splitting it into separate adder and inc/dec circuit? A common problem with many designers is that they want to over-design something that is really pretty simple. Try the simple way and see if it works first, before going into more detail to tell the synthesis tool how you think it ought to be done. signal accum : signed(23 downto 0) := (others => '0'); signal input : signed(13 downto 0) := (others => '0'); ... --inside a clocked process: accum <= accum + input; AndyArticle: 147717
Andy wrote: > signal accum : signed(23 downto 0) := (others => '0'); > signal input : signed(13 downto 0) := (others => '0'); > ... > --inside a clocked process: > accum <= accum + input; operand size mismatch spotted... > Andy yg -- http://ygdes.com / http://yasep.orgArticle: 147718
On May 13, 11:11=A0pm, Sharath Raju <brshar...@gmail.com> wrote:
>
> > > >>>> The problem is this bit of code:
>
> > > >>>> process (Inc_cnt, Dec_cnt)
There is your problem...using non-clocked processes...with an
incomplete sensitivity list to boot.
> > > >>>> begin
> > > >>>> =A0 =A0if Inc_cnt =3D '1' then
> > > >>>> =A0 =A0 =A0Int_count<=3D Int_count + 1;
> > > >>>> =A0 =A0elsif Dec_cnt =3D '1' then
> > > >>>> =A0 =A0 =A0Int_count<=3D Int_count - 1;
> > > >>>> =A0 =A0end if;
>
> > > >>>> end process;
>
>
> I don't want the process (Inc_cnt, Dec_cnt) to be a clocked process.
Why not?
> Inc_cnt and Dec_cnt are control signals that if set, either increment
> or decrement the Int_count counter signal. Hence the reason for
> putting Inc_cnt and Dec_cnt in the sensitivity list.
>
Neglegting to put the signal 'Int_count' is the reason you also have a
warning about an incomplete sensitivity list that you've ignored. It
is also the reason why your simulation will not match the actual
synthesis result under certain conditions either...but that's further
down your road if you continue on the path that you seem determined to
follow.
> The purpose of the code is to :
> 1. delay del_X signal by one clock cycle,
> 2. Multiply X (8-bit) and del_X (8-bit), and accumulate the product
> into a register Y (24 bit).
>
OK
> I have split the accumulation into two steps.
> 14 bit addition (Sum signal) , followed by a 10-bit counter that
> updates the (Int_count signal) if an overflow (Inc_cnt signal) or a
> borrow (Dec_cnt signal) is generated by the addition operation.
The counter needs to be inside a clocked process...end of story. See
below for a template to follow.
If you then also need the updated counter to be on the same clock
cycle as the output of the other calculations, then you can
- Delay the other calculations by one clock cycle so they are in sync
with the counter
- Precompute the counter and use that (see code below)
Kevin Jennings
************************************************
-- Start of code for pre-computing the next state of counter 'early'
Next_Int_count_Almost<=3D (Int_count + 1) when (Inc_cnt =3D '1' ) else
Int_count<=3D Int_count - 1;
Next_Int_count <=3D Next_Int_count_Almost when (Inc_cnt =3D '1' ) or
(Dec_cnt =3D '1' ) else Int_count;
The above two can also be combined into one concurrent
statement...I'll leave that as an exercise for the reader.
Lastly, you have to update 'Int_count'. Here is the traditional
way...
process (Clock)
begin
if rising_edge(Clock) then
if (...need some form of reset) then
Int_count<=3D 0;
else
Int_count <=3D Next_Int_count;
end if;
end if;
end process;
-- End of code for pre-computing the next state of counter 'early'
************************************************
************************************************
-- Start of code for synchronous counter
process (Clock)
begin
if rising_edge(Clock) then
if (...need some form of reset) then
Int_count<=3D 0;
elsif Inc_cnt =3D '1' then
Int_count<=3D Int_count + 1;
elsif Dec_cnt =3D '1' then
Int_count<=3D Int_count - 1;
end if;
end if;
end process;
-- End of code for synchronous counter
************************************************
Article: 147719Sharath Raju <brsharath@gmail.com> wrote: >On May 16, 11:07=A0am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote: >> Am 13.05.2010 16:18, schrieb John McCaskill: >> >> > The problem is this bit of code: >> >> > process (Inc_cnt, Dec_cnt) >> > begin >> > =A0 if Inc_cnt =3D '1' then >> > =A0 =A0 Int_count <=3D Int_count + 1; >> > =A0 elsif Dec_cnt =3D '1' then >> > =A0 =A0 Int_count <=3D Int_count - 1; >> > =A0 end if; >> >> > end process; >> >> > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the >> > clock. >> >> You pointed out a very bad piece of code, but it is not a flipflop - it >> is a latch as rickman has already pointed out. >> >> It has 2 big design errors: >> >> 1) muxed latch: Inc_cnt and Dec_cnt drive latch-enable and mux-select. >> This is very bad design because no one can say if the latch-enable or >> the mux-select chances first in the moment when Inc_cnt / Dec_cnt become >> inactive. >> >> 2) infinite loop: As long as Inc_cnt / Dec_cnt is enable, Int_count is >> incremented / decremented. During simulation this problem did not show >> up, because the sensitivity list of this process is incomplete. Put >> Int_count into the sensitivity list and the simulator will freeze forever= >. >> >> Ralf > >I have rewritten the bad piece of code, but still a latch is >synthesized for Int_count signal. Can anybody tell what is wrong with >this piece of code ? > >process (Inc_cnt, Dec_cnt, RST) >begin > if RST =3D '0' then > Int_count <=3D (others =3D> '0'); > elsif Inc_cnt =3D '1' then > Int_count <=3D Int_count + 1; > elsif Dec_cnt =3D '1' then > Int_count <=3D Int_count - 1; > else > Int_count <=3D Int_count + 0; -- I want to do a "no operation" here. > end if; > >end process; It must be clocked. There is no other way around it. The logic will not work in an FPGA due to variance in routing delays. For each bit of Int_count there will be a latch. Each of those latches will have a combinatorial piece of logic which also depends on the other latches. The delays to generate each latch's output signal will vary for each latch. If you set the latch enable to '1' your latched counter will start to 'count' at an undefined rate problaby producing errating states and consume a lot of power (heat up the FPGA). Take your code and try to simulate the routed version and see what happens. As long as the code doesn't work in the simulator it will most definitely not work in a real device. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147720
> 2mm pitch is a good size/strength/standard compromise, but I'd not > stop at 2x3/2mm; such a standard, should > have more than one size, the others being super-sets. > So the minimum common subset, is 2x3, then you add another 2x3 for > example, to allow more test signals. > With FT2232 and FT2232H becoming standard, there are a lot of unused > (but paid for) signals sitting right next to the JTAG ones. I'm really just talking about manufacturers JTAG/programming headers. There are too many other proprietary combinations to 'standardise'. IMHO. NialArticle: 147721
Hi all, SUPPRESSED by archive owner as a favor to original authorArticle: 147722
HIDDEN <zzzz@gmail.com> writes: > SUPPRESSED by archive owner as a favor to original author I would suggest you: 1) Get an Aptina developer board. Learn how the sensor works and how to set the correct register values for your application. 2) Dump the raw Bayer data to files and use this as input for your image processing algorithms. If you have to develop these you're probably better off doing so in Matlab or in your favorite programming language than in HDL at this point. 3) Start on your HDL code and verification environment. You can use the Bayer files from step 2 and the resulting data from your Matlab (or whatever) models to check the correctness of your HDL implementation. 4) Now you can start with your FPGA. There are IP from various sources, included some of the FPGA vendors to do image processing. Petter -- .sig removed by request.Article: 147723
On 19 mai, 11:12, Petter Gustad <newsmailco...@gustad.com> wrote: > I would suggest you: > > 1) Get an Aptina developer board. Learn how the sensor works and how > to set the correct register values for your application. > > Petter > -- > .sig removed by request. Thank you for advices, I have several questions: 1 what does it mean by dumping the raw Bayer data to files, should I use third part software to get the .raw file then use them as resources in matlab? Is there anyway to get the data directly in matlab? 2 After doing the processing in Matlab, how can I use the code in my HDL implementation? Do I need to convert matlab code into VHDL or Verilog? 3 How long do you think it will take to get the matlab part done? Thanks againArticle: 147724
HIDDEN <zzzz@gmail.com> writes: > 1 what does it mean by dumping the raw Bayer data to files, should I > use third part software to get the .raw file then use them as > resources in matlab? Is there anyway to get the data directly in > matlab? I think that at least some of the older Aptina boards have an USB interface and the ability to dump the frames to the host. You can read the files into Matlab using fread. You could also inspect the data visually using demosaic and imtool (assuming you have the image processing toolbox). > 2 After doing the processing in Matlab, how can I use the code in my > HDL implementation? Do I need to convert matlab code into VHDL or > Verilog? You can use the output of your Matlab model and compare it to the output of your HDL simulation. > 3 How long do you think it will take to get the matlab part done? That depends upon what kind of processing you want to do. It could be anywhere from minutes to several years. Petter -- .sig removed by request.
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