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
Brian Davis wrote: > Ray Andraka wrote: > >>For one or two it seems to work. For many, it slows PAR way down >>and usually won't find a solution where all the maxdelays get met >> > > Ok, that sounds (dare I say) about par for the course... > > Have you ever gotten anywhere in convincing Xilinx to add a flag > to the router to restore the old, more consistent, behavior? > NO, and the answer I get back is "ain't gonna happen". > >>not to mention making the UCF a nightmare. > > > I just stuck the MAXDELAYs in the source near the net keep directives. I'll have to try that. I've put other xilinx attributes like HU_SET and TNM in the source, but hadn't thought about putting the MAXDELAYs in the source. > > I have enough UCF nightmares already; on the bright side, at least > they haven't made the UCF a binary file yet :) > Ssshhhh! Don't give them any ideas.Article: 99551
Antti Lukats wrote: > that *IS* possibe, but usually VERY time-consuming and from that point of > view un reasonable. Not Really. More a matter of the lack of automated tools. Bit stream to schematic should be relatively easy, and not that much harder to some reasonable HDL or HLL. I've done software reverse engineering since the late 1960's, including source reconstruction for an entire operating systems and utilities in the early 70's. Included was a contract to reconstruct an entire firmware control system from Z80 prom binaries in a couple dozen 26C512s back to the original asm and forth, then write a clean room specification for it's reimplementation in the mid 90's. I would guess that if someone got serious about it, and didn't have DMCA restrictions, the whole tools project could be knocked off by a one-two people well inside a year, if not a few months. What might really be fun is doing a boomerang front end for it, and decompile to Handel-C or FpgaC. Boomerang has been useful for small projects for several years, and is maturing well. Have fun, John http://sourceforge.net/projects/boomerangArticle: 99552
If it's a paying project, or a school project, consider using handel-C in the Celoxica product, or their newer System C offerings, for a mature production compiler. Mixed C and VHDL should be a minor problem with some planning.Article: 99553
Arash Majd wrote: > Hello Dear friends > Thanks for all your careful attentions. > I found the solutions. I have set the slew rate setting to slow instead > of fast. When I did this,The jitter came down to .05 UIpp. > > Arash Majd Good to hear you did not need a new PCB design :) The fast/slow is not well explained in most data, as it also means HiDrive/LoDrive, and thus more ground bounce can come from Fast(HiDrive). ie unless the last ns matters on long lines, use Slow... Did you try fast only on the ClkOUT pin, and Hysteresis on/off on the clock IP node ? -jgArticle: 99554
In message <e06785$oab$1@online.de>
"Antti Lukats" <antti@openchip.org> wrote:
> "Tank" <webmaster@tankstage.co.uk> schrieb im Newsbeitrag
> news:9d55af0d4e.tank@tankstage.co.uk...
> > In message <1143359330.846497.90580@j33g2000cwa.googlegroups.com>
> > mikeotp@gmail.com wrote:
> >
> >> regards
> >>
> >> is it possible from the driver of a chip and pin assignment
> >>
> >> of a chip to reverse a chip,and to produce the same chip?
> >>
> >>
> >> any positive suggestion is welcome
> >> best regards to you all
> >>
> > On a similar note, is it possible to get back to the design from a .bit
> > file?
> >
> > Cheers
> >
> > Tank
> > --
> > webmaster@tankstage.co.uk
> > Iyonix PC
>
> that *IS* possibe, but usually VERY time-consuming and from that point of
> view un reasonable.
>
> Antti
>
>
Would it be a case of plodding through the file, searching the FPGA spec
sheet and then writing the schematic (I'm using loose terms as I am only just
"getting into" FPGA's).
Cheers
Tank
--
webmaster@tankstage.co.uk
Iyonix PC
Article: 99555Maki wrote: > <snip> <snip> > constant ROM : rom_type :=( > "0001","0010","0011","0100","0101","0110","0111","1000","1001", > etc. Ahhh Maki, A thousand thanks to you! This does indeed synth down to a BRAM, with the desired synchronous reset. Of course I'd tried variations from the XST user guide, but it turned out that I'd blundered and used a formation of: signal ROM : rom_type :=( "0001","0010","0011","0100","0101","0110","0111","1000","1001", instead of "constant ROM", which was what impeded XST from doing it's impressive job. So my apologies to the XST developers, and I remain, Just JohnArticle: 99556
This "Behavioral style" is an attempt to optimize for faster simulation. In reality, it may end up running a lot slower, depending on your simulator.Article: 99557
JustJohn wrote: > Maki wrote: > > <snip> > <snip> > > constant ROM : rom_type :=( > > "0001","0010","0011","0100","0101","0110","0111","1000","1001", > > etc. Going back to my code, I actually did use the correct construction. It turns out that my PROM is 4K deep, and that produces the annoying message: "Currently unable to implement this ROM as a read-only block RAM.", While Maki's example, which is only 32 words deep, produces the unhappy result: "The register is removed and the ROM is implemented as read-only block RAM." Listen up Xilinx. This is the EXACT OPPOSITE of what almost any designer would want: Big PROMs should go into BRAM, small PROMs should go into distRAM. My apologies for being irked by this behavior, but it seems like such a simple thing... While my dander is up, I'll also take this moment to gripe about the newest 8.1i ISE GUI. Who's idea was it to add the explicit left click "Set as top module"? This is as buggy as anything in the GUI. Has anybody else out there noticed that sometimes (often!) it gets recalcitrant, and refuses to put the Implement Design selection into the Process window sometimes? I just wasted 10 minutes trying to get the system to accept that I wanted to take a test design "Test_Maki" through to PAR. I could click on other modules, set them as top, but the particular one I wanted, it refused. Really bothersome. I far preferred the way 7.1 worked: single click - set as top; double click - open for edit. Was there a study group that decided on this particular change? How do I get into one of those? (Always, my apologies for complaining, but it's Sunday and here I am at the office, instead of being out sailing on a nice sunny SoCal day). On to Antti's suggestion.Article: 99558
Antti wrote:
> oh there are zillions of mockups, gotta get used to that.
>
> for your case you may try using a "fake" 0 or 1, eg a signal that is
> constant but is not recognized as constant by xilinx flow, this is
> clever trick that helps in many different cases :)
>
> Antti
Hey Antti,
(Thanks for your time!) Success at last. Sure, I'd thought of that,
or tying off to an unused I/O pin, but this seemed so painfully
convoluted. After mucking about with Maki's suggestion (see the other
branch) I came back to yours. I used the RAM construct as posted at the
start of this topic, and then produced a Dummy_Zero as follows:
signal Dummy_Ctr : UNSIGNED( 0 downto 0 );
signal Dummy_Sum : UNSIGNED( 0 downto 0 );
signal Dummy_Zero : std_logic;
...
process( Clk ) begin
if RISING_EDGE( Clk ) then Dummy_Ctr <= Dummy_Ctr + 1;
end if; end process;
Dummy_Sum <= Dummy_Ctr + 1;
Dummy_Zero <= '1' when Dummy_Sum = Dummy_Ctr else '0';
One last question I'll leave the group with, does anyone know a simpler
way to produce a Dummy_Zero?
Finally, to the Xilinx folks, I know the GUI garbage is much more
MicroSoft's fault than yours (they keep fixing things that aren't as
badly broken as the fix is), keep up your noble efforts!
Regards All,
John
Article: 99559Hi Clark, Anonymous wrote: > Does anybody know if/where a pre-made linux build for the memec v4 fx12 > mini-module development kit? PPC linux preferred but microblaze is fine too. > I'm just doing software evaluation and measuring power consumption so any > linux is fine. I'm not interest in the source files now, just what ever > programming files I need for the board to get a console and network > interface. We can do you a Linux bringup for PPC or MicroBlaze. Contact me directly and we'll work something out. Regards, John -- Dr John Williams, Research Fellow, Embedded Systems Group / Reconfigurable Computing School of ITEE, The University of Queensland, Brisbane, Australia (p) +61 7 33652185 (f) +61 7 33654999 (m) +61 403969243Article: 99560
The Altera web site has been inaccessible now for over 48 hours. Further investigation this evening shows that only certain clients are blocked. (I can see their home page via a proxy, but that proxy won't let me download large documents). A "tracert" reaches somewhere in Santa Clara. From consultation with another, at least two large ISPs in the UK are blocked. Does anyone know why they do this? I wanted to download one of their PDF documents, but the site don't respond (even to pings). I'm still at the development kit stage and everything I've seen of Altera so far makes me think "Surely Xilinx can't be as bad as this?". It's difficult to see how we can ever use Altera products when they block our access to their site.Article: 99561
I believe that the MAXDELAY constraint applies to the actual net delay and does not include clock->Q propagation delay or setup time. So if your target is 400MHz, 2.5 ns is NOT the right value. This trick may have worked for me, but because sometimes PAR does OK and sometimes it doesn't it's hard to say for sure that MAXDELAY is a sure fire work-around to force PAR to do the right thing. It is very annoying that having told PAR how to place two block so that it can succeed, it then messes up a very simply route and misses timing. This sure seems like low-lying fruit that the Xilinx s/w folks could pick. John ProvidenzaArticle: 99562
JustJohn wrote: (See Google Groups if you want the history)
Back to being a cautionary tale... Thought I'd be clever, and fake a 4K
x 8 PROM by coding a 4Kx8 RAM with initial values _and_ a set/reset
value (code below). Looked like it worked, but then I opened FPGA
Editor, and it reports that the S/R Val A is 0, rather than the value I
coded. I guess that you only get either initial values or S/R value,
but not both. I look forward to service pack 4...
Just John
This code produces erroneous bitstream for XST:
constant Init_Val : std_logic_vector( 7 downto 0 ) := x"06";
type RAM_Type is array ( 0 to 4095 )
of std_logic_vector (7 downto 0);
signal RAM : RAM_Type :=(x"01", x"02", x"03", 4K of yadda,
signal Dummy_Ctr : UNSIGNED( 0 downto 0 );
signal Dummy_Sum : UNSIGNED( 0 downto 0 );
signal Dummy_Zero : std_logic;
signal Dummy_Input : UNSIGNED( 7 downto 0 );
...
begin -- Architecture
process( Clk ) begin
if RISING_EDGE( Clk ) then
Dummy_Ctr <= Dummy_Ctr + 1;
Dummy_Input <= Dummy_Input + 1;
end if;
end process;
Dummy_Sum <= Dummy_Ctr + 1;
Dummy_Zero <= '1' when Dummy_Sum = Dummy_Ctr else '0';
process ( Clk ) begin
if RISING_EDGE( Clk ) then
if CE = '1' then
if Dummy_Zero = '1' then
RAM( TO_INTEGER( UNSIGNED( A ))) <=
std_logic_vector( Dummy_Input );
end if;
if Rst_n = '0' then
O <= Init_Val;
else
O <= RAM( TO_INTEGER( UNSIGNED( A )));
end if; end if; end if;
end process;
Article: 99563Brian - Somehow I managed to miss this series of posts earlier, but found them today. Thanks very much for posting your simulations. Bob Perlman Cambrian Design WorksArticle: 99564
Hi, We are developing a product that passes data between an xDSL interface and a proprietory optical interface. We are using a Spartan 3 FPGA. The xDSL chipset generates an 8.192MHz clock that is recovered from the DSL line. (The xDSL chipset uses a digital phase locked loop for this). The current FPGA design uses this clock internally, and uses it to clock the optical interface also. Single clock domain, nice. However, there is now a requirement to clock the optical interface at a higher rate. How to generate this clock? Xilinx DCM Frequncy Synthesizer would seem to be the obvious choice. However the DCM jitter tolerance requirements are the order of +-1ns period jitter and +-300ps cycle-cycle jitter. I'm very worried the xDSL 8.192MHz clock will exceed this jitter tolerance. The xDSL chipset doesn't specify any jitter characteristics, and anyhow its likely dependent on the characteristics of upstream DSL equipment. So I have ruled out this path as too risky. The DCM jitter tolerance feels like quite a limitation of the DCM so probably I'm not understanding how I can make use of the DCM's in my application. Does anyone have any hints of practicle FPGA techniques for generating a higher clock? A doubling of the clock frequency would be enough. Just the name of a technique would be enough to get me googling... The xdsl chipset also has a local oscillator at 22MHz - but it just free runs of course...I could invisage a plesiosynchronous scheme where the optical link runs at 22MHz and I bit stuff to get the required data rate. But it feels too complex, overkill. And then I have to think more carefully about the optical link clock recovery at the far end. (Keeping the number of clock domains to a minimum is of course a desireable goal). Regards AndrewArticle: 99565
On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman <allanherriman@hotmail.com> wrote: >>> dff #4 park_reg(.din (next_pv), >>> .clk (clk), >>> .q (park_vec), >>> .se (se), .si(), .so()); ... >dff isn't a gate primitive, so it must be a UDP. However, it seems >that the standard only allows ordered parameter assignments and not >named parameter assigments for UDPs. > > >Therefore the code isn't legal according to the standard. > >This seems to be a mistake in the standard. Does anyone know why it >doesn't allow named parameter assignments for UDPs? I must be missing something. Why is a named parameter assignment needed ? Isn't this an ordered parameter assignment ?Article: 99566
Andrew FPGA wrote: > Does anyone have any hints of practicle FPGA techniques for generating > a higher clock? A doubling of the clock frequency would be enough. Just > the name of a technique would be enough to get me googling... > > Regards > Andrew Look for Peter Alfke's tech note "Five easy pieces" or "Nine easy.." or whatever, I think he has a simple clock doubler in there (generates a short pulse for each edge of the source clock), or look through this group some more. You'll find a bit of discussion on that circuit. If you're worried about jitter on your generated clock though, it will be at least as much as your input clock... JohnArticle: 99567
johnp wrote: > > I believe that the MAXDELAY constraint applies to the actual net delay > and does not include clock->Q propagation delay or setup time. So > if your target is 400MHz, 2.5 ns is NOT the right value. > Right, it doesn't replace the timing constraints, just forces the router to look for a route with delay shorter than the constraint you've set for that net. Sorry if my explanation was a bit murky, let me try again: If the value you set is less than physically possible in the part, PAR will bail out saying such a route does not exist; that's why I'd mentioned looking up the delays in fpga_editor first: then you set MAXDELAY just barely above the delay of the routing path you want to hit, so that the router has no other available choice. It may also help to make the delay values a set of constants so you can change them easily if moving parts or speed grades. > > This trick may have worked for me, but because sometimes PAR does OK > and sometimes it doesn't it's hard to say for sure that MAXDELAY is a > sure fire work-around to force PAR to do the right thing. > I've used it just for small critical bits of logic ( like synchronizers, DDR capture stages), and the ones I've checked have looked OK. Given the "physically impossible route" warnings from PAR, my hope is that this constraint is checked early on before the first attempted route of the net, thus forcing usage of the shortest interconnections from the very beginning of the routing process. Ray has pointed out that he's seen problems with wholescale usage of the MAXDELAY constraint choking PAR, so it doesn't seem to be suitable for mass application. BrianArticle: 99568
It's "six easy pieces" in TechXclusives, but: That is just a differentiator of the two clock edges, with a bit of smarts thrown in. The output jitter is the input jitter plus anything due to duty cycle difference from 50%. There are of course external PLL circuits (I have used ICS, but there are many suppliers). That means an external part plus extra money... Peter AlfkeArticle: 99569
Andrew wrote: > >Does anyone have any hints of practicle FPGA techniques for generating >a higher clock? A doubling of the clock frequency would be enough. Just >the name of a technique would be enough to get me googling... > If the 8.192 clock were differential, and the duty cycle good, you could feed it into one of the differential input buffers and use the DIFF_OUT buffer feature to generate an internal complementary 8.192 MHz clock suitable for DDR I/O operation. You'd then forward the DDR clock and DDR data to the optical interface, which would need to accept a half rate clock. If the clock source is single ended and fixed rate, a simple RC +/- 45 degree phase shifter could probably get you a differential version cheaply, or just use a single-gate CMOS-in LVDS-out driver chip. BrianArticle: 99570
Brian Davis wrote: > It may also help to make the delay values a set of constants > so you can change them easily if moving parts or speed grades. and don't forget speed file upgrades.....:) -jgArticle: 99571
I wrote: > > If the clock source is single ended and fixed rate, a simple > RC +/- 45 degree phase shifter could probably get you a > differential version cheaply, or just use a single-gate >CMOS-in LVDS-out driver chip. Ooops, that'd make 90 instead of 180 degrees; I think you can get there with a narrowband LC balun, but the LVDS driver may be simpler. BrianArticle: 99572
On Mon, 27 Mar 2006 01:12:41 GMT, mk <kal*@dspia.*comdelete> wrote: >On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman ><allanherriman@hotmail.com> wrote: > >>>> dff #4 park_reg(.din (next_pv), >>>> .clk (clk), >>>> .q (park_vec), >>>> .se (se), .si(), .so()); >... >>dff isn't a gate primitive, so it must be a UDP. However, it seems >>that the standard only allows ordered parameter assignments and not >>named parameter assigments for UDPs. >> >> >>Therefore the code isn't legal according to the standard. >> >>This seems to be a mistake in the standard. Does anyone know why it >>doesn't allow named parameter assignments for UDPs? > >I must be missing something. Why is a named parameter assignment >needed ? Isn't this an ordered parameter assignment ? In the above code, ( .din(next_pv), .clk(clk), .q(park_vec), .se(se), .si(), .so() ) is a named parameter assignment. An ordered parameter assignment would look more like ( next_pv, clk, park_vec, se ) Regards, AllanArticle: 99573
Jim wrote:
>
>and don't forget speed file upgrades.....:)
>
OK, but the actual implementation of calc_max_delay
is left as an exercise for the reader :)
attribute maxdelay of my_net : signal is
calc_max_delay
(
desired_path_type,
part_type,
speed_grade,
ise_version,
speed_file_version,
phase_of_moon
);
Brian
Article: 99574I wrote: > > Ooops, that'd make 90 instead of 180 degrees; I think > you can get there with a narrowband LC balun, but the > LVDS driver may be simpler. As further evidence that I shouldn't type late at night, at those data rates the local DDR IOB clock inversion would work just fine for generating 16.384 Mbps DDR data. So if you can tweak your optical interface to accept a half rate clock with DDR data, you should be OK with your present FPGA clocking setup. Brian
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