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
Dear all, I am very new in vhdl, can anybody tell me what problem, following is code : disp_ena : OUT STD_LOGIC; --) column : OUT INTEGER; -- row : OUT INTEGER;: .......................................... --set pixel coordinates IF(h_count < h_pixels) THEN --horiztonal display time column <= h_count; --set horiztonal pixel coordinate END IF; IF(v_count < v_pixels) THEN --vertical display time row <= v_count; --set vertical pixel coordinate END IF; --set display enable output IF(h_count < h_pixels AND v_count < v_pixels) THEN --display time disp_ena <= '1'; --enable display ELSE --blanking time disp_ena <= '0'; --disable display END IF; AND it has following ERROR ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" Line 67. Signal 'column' column is at left hand side of variable assignment statement. ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" Line 68. Signal 'row' row is at left hand side of variable assignment statement.Article: 158426
On 2015-11-19 16:24:00 +0000, abirov@gmail.com said: > Dear all, I am very new in vhdl, can anybody tell me what problem, > following is code : > disp_ena : OUT STD_LOGIC; --) > column : OUT INTEGER; -- > row : OUT INTEGER;: > .......................................... > --set pixel coordinates > IF(h_count < h_pixels) THEN --horiztonal display time > column <= h_count; --set horiztonal pixel coordinate > END IF; > > IF(v_count < v_pixels) THEN --vertical display time > row <= v_count; --set vertical pixel coordinate > END IF; > > --set display enable output > IF(h_count < h_pixels AND v_count < v_pixels) THEN --display time > disp_ena <= '1'; --enable display > ELSE --blanking time > disp_ena <= '0'; --disable display > END IF; > AND it has following ERROR > > ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" > Line 67. Signal 'column' column is at left hand side of variable > assignment statement. > ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" > Line 68. Signal 'row' row is at left hand side of variable assignment > statement. You didn't provide line numbers with your listing but look at the third line closely and you will see what might be causing the problem.Article: 158427
Am Donnerstag, 19. November 2015 17:24:13 UTC+1 schrieb abi...@gmail.com: > Dear all, I am very new in vhdl, can anybody tell me what problem, > following is code : > disp_ena : OUT STD_LOGIC; --) > column : OUT INTEGER; -- > row : OUT INTEGER;: > ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" Line 67. Signal 'column' column is at left hand side of variable assignment statement. > ERROR:HDLParsers:409 - "D:/xil_add/1/eewiki_vga/vga_controller.vhd" Line 68. Signal 'row' row is at left hand side of variable assignment statement. You did not provide the relevant part of code. "column" and "row" are outputs and therefore signals, the errormessage indicates you use them in variable assignment (row := ABC) instead of signal assignments (row <= ABC) in line 67 and 68. regards, ThomasArticle: 158428
Here is my code,here is no errors and warnings, but even no warnings and no= errors (i think adv7125 problem) it doesnot work.I have old ML405 board an= d it use ADV7125,and monitor is Acer AL1511 used 1024X768,I use LED out for= checking whether is reset works or not, and also checked for CLK (LED <=3D= clk65MHZ)so thats ok, Here is all code: (vga.vhd) library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.Numeric_STD.All; entity VGA is port ( clk100MHz : in std_logic; reset_n : in std_logic; HSYNC : out std_logic; VSYNC : out std_logic; VGA_R,VGA_G,VGA_B: out std_logic_vector(3 downto 0); VGA_CLK : out std_logic; LED : out std_logic ); end VGA; architecture main of vga is=20 signal clk65MHz: std_logic:=3D'0'; ------------------------------------------------------------- component clock port ( clk100MHz: in std_logic; clk65MHz: out std_logic ); end component; ------------------------------------------------------------- component SYNC=20 port ( clk65MHz : in STD_LOGIC; reset_n: in STD_LOGIC; HSYNC,VSYNC : OUT STD_LOGIC; --LEDo,LED1o : OUT STD_LOGIC; VGA_R,VGA_G,VGA_B : OUT STD_LOGIC_VECTOR(3 downto 0) ); end component; --------------------------------------------------------------- begin C1: SYNC port map (clk65MHz,reset_n, HSYNC, VSYNC, VGA_R =3D> VGA_R, VGA_G =3D> VGA_G, VGA_B =3D> VGA_B ); C2 : clock port map (clk100MHz,clk65MHz); LED <=3D reset_n; VGA_CLK <=3D clk65MHz; end main; (*.vhd) library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity SYNC is PORT( reset_n: in STD_LOGIC; clk65MHz: in STD_LOGIC; HSYNC,VSYNC : OUT STD_LOGIC; VGA_R,VGA_G,VGA_B : OUT STD_LOGIC_VECTOR(3 downto 0) ); end SYNC; architecture main of SYNC is SIGNAL HPOS: INTEGER RANGE 0 TO 1344:=3D0; --1688:=3D0; SIGNAL VPOS: INTEGER RANGE 0 TO 806:=3D0; --1066:=3D0; begin process (clk65MHz,reset_n) begin=20 IF rising_edge(clk65MHz) and reset_n =3D '1' then if HPOS=3D740 or VPOS=3D554 then VGA_R<=3D(OTHERS=3D>'1'); VGA_G<=3D(OTHERS=3D>'1'); VGA_B<=3D(OTHERS=3D>'1'); else VGA_R<=3D(OTHERS=3D>'0'); VGA_G<=3D(OTHERS=3D>'0'); VGA_B<=3D(OTHERS=3D>'0'); end if; if HPOS<1344 then=20 HPOS<=3DHPOS+1; else HPOS<=3D0; if VPOS<806 then VPOS<=3DVPOS+1; else VPOS<=3D0; end if; end if; =20 if HPOS>24 and HPOS<160 then HSYNC<=3D'0'; else HSYNC<=3D'1'; end if; =20 if VPOS>3 and VPOS<9 then VSYNC<=3D'0'; else VSYNC<=3D'1'; end if; =20 if ((HPOS>0 and HPOS<320)or(VPOS>0 and VPOS<38))then VGA_R<=3D(others=3D>'0'); VGA_G<=3D(others=3D>'0'); VGA_B<=3D(others=3D>'0'); end if; end if; end process; end main; clock.vhd library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity clock is port ( clk100MHz: in std_logic; clk65MHz: out std_logic ); end clock; architecture Behavioral of clock is=09 signal Counter: std_logic_vector(25 downto 0); signal CLK_1Hz: std_logic; =09 begin Prescaler: process(clk100MHz) begin if rising_edge(clk100MHz) then if Counter < "10111110101111000010000000"=20 then Counter <=3D Counter + 64999999; else CLK_1Hz <=3D not CLK_1Hz; Counter <=3D (others =3D> '0'); end if; end if; end process prescaler; clk65MHz <=3D CLK_1Hz; end Behavioral;Article: 158429
On Saturday, November 28, 2009 at 10:27:24 PM UTC+6, Gabor wrote: > On Nov 28, 9:29=A0am, "lalop" <euar...@yahoo.com.mx> wrote: > > I am an electronics student and pretty new in FPGAs' use. > > > > I am interested in to send images to a monitor from the FPGA. > > I have already performed a test using the Spartan 3 xilinx board based = on > > an example I found at the Internet and it worked perfectly. Now I am tr= ying > > to translate the same example to the ML405 xilinx board, however it doe= sn't > > work correctly. > > > > I wonder if someone could give me a hand to solve this problem. I add m= y > > vhdl code and ucf file > > > > lalo > > > [snip] >=20 > lalo, >=20 > In what way doesn't it work right? I assume you pretty much copied > the code from the other project. You did check the pinout definitions > in your .ucf file against the board documentation? >=20 > Does the Virtex 4 board have the same hardware for VGA output > (D/A Converter or just resistors) as the old board? Most video > D/A Converters need a clock signal as well as synch and data. >=20 > Your clocking is a bit of a mess. I imagine you may have > inherited some of it from the prior project, but it's not > generally good practice to make ripple counters in an FPGA. >=20 > Your net clk25 in the .ucf doesn't correspond to a top > module port. Is this supposed to drive the D/A converter > clock? >=20 > Regards, > Gabor Gabor, lalo I meet similar problem, and gave clk to adv7125, as I mentione= d in my post https://groups.google.com/forum/#!topicsearchin/comp.arch.fpga/vga/comp.arc= h.fpga/l8t2fDa2TVE lalo did you get some success or not ? but there are no any result yet.Article: 158430
my UCF file, NET "clk100MHz" LOC = "AB14"; --clock from ML405 clock generator NET "VGA_CLK" LOC = "AC7"; --clock to ADV7125 NET "reset_n" LOC = "d6"; NET "LED" LOC = "A10"; #NET "LED1" LOC = "B10"; #NET "LED2" LOC = "F13"; ####################### VGA ###################### NET "VGA_B<0>" LOC = "f4" ; NET "VGA_B<1>" LOC = "j4" ; NET "VGA_B<2>" LOC = "g9" ; NET "VGA_B<3>" LOC = "j5" ; #NET "VGA_B<4>" LOC = "h3" ; NET "VGA_G<0>" LOC = "j3" ; NET "VGA_G<1>" LOC = "k7" ; NET "VGA_G<2>" LOC = "k3" ; NET "VGA_G<3>" LOC = "g10" ; #NET "VGA_G<4>" LOC = "k6" ; NET "VGA_R<0>" LOC = "f3" ; NET "VGA_R<1>" LOC = "h7" ; NET "VGA_R<2>" LOC = "e3" ; NET "VGA_R<3>" LOC = "g5" ; #NET "VGA_R<4>" LOC = "d3" ; ##################### SYNCs ######################## NET "HSYNC" LOC = "C3" ; NET "VSYNC" LOC = "D4" ;Article: 158431
On Friday, January 26, 2007 at 12:34:59 AM UTC+6, gso...@gmail.com wrote: > Thanks por the advice, I'm going to modify my ADV7125 driver to work > with HSYNC VSYNC and CLK signals only. > > Regards > > Gerardo I use ML405 did same things for my board but there is not success, can you explain what are these things means , may be i need to change something to adopt to my board ?Article: 158432
On Mon, 23 Nov 2015 03:44:50 -0800, abirov wrote: > On Friday, January 26, 2007 at 12:34:59 AM UTC+6, gso...@gmail.com > wrote: >> Thanks por the advice, I'm going to modify my ADV7125 driver to work >> with HSYNC VSYNC and CLK signals only. >> >> Regards >> >> Gerardo > > I use ML405 did same things for my board but there is not success, can > you explain what are these things means , may be i need to change > something to adopt to my board ? That post is nearly 9 years old, so he has probably forgotten by now. -- BrianArticle: 158433
On Monday, November 23, 2015 at 5:48:25 PM UTC+6, Brian Drummond wrote: > On Mon, 23 Nov 2015 03:44:50 -0800, abirov wrote: > > > On Friday, January 26, 2007 at 12:34:59 AM UTC+6, gso...@gmail.com > > wrote: > >> Thanks por the advice, I'm going to modify my ADV7125 driver to work > >> with HSYNC VSYNC and CLK signals only. > >> > >> Regards > >> > >> Gerardo > > > > I use ML405 did same things for my board but there is not success, can > > you explain what are these things means , may be i need to change > > something to adopt to my board ? > > That post is nearly 9 years old, so he has probably forgotten by now. > > -- Brian Yep ))))Article: 158434
There's a new FPGA development board on Kickstarter. It's called the Nandl= and Go Board, and it aims to be an inexpensive, easy-to-use FPGA developmen= t board to learn about how FPGAs work and what they are capable of. This b= oard is unique because it provides a lot of options for projects built dire= ctly into the board. It comes with:=20 - Four LEDs - Four Push-Button Switches - Two 7-Segment LED displays - Micro USB Connector (for Programming and Communication) - VGA Connector - External Connector Most other FPGA development boards come with just a simple connector but th= e Go Board has lots of functionality built right into it. The Kickstarter = page shows a bunch of examples of what is possible using the Nandland Go Bo= ard, and it's pretty impressive. You can even program it to play Pong! Ta= ke a look at the Kickstarter page and pick one up today. For the past two years I've been working on building up a large amount of e= xamples and tutorials for people who want to learn about FPGAs. My website= www.nandland.com shows you how to get started with VHDL or Verilog, and is= accessible for anyone, even if you've never used an FPGA before. =20 I wanted to share with you my Kickstarter campaign which just launched. I = am hoping that you find it fun and educational. Would you be willing to pu= t up a short post that promotes it? Below is an example of what you might = be able to say. I really would appreciate any support I can get, so thank = you. Example Post: There's a new FPGA development board on Kickstarter. It's called the Nandl= and Go Board, and it aims to be an inexpensive, easy-to-use FPGA developmen= t board to learn about how FPGAs work and what they are capable of. This b= oard is unique because it provides a lot of options for projects built dire= ctly into the board. It comes with:=20 - Four LEDs - Four Push-Button Switches - Two 7-Segment LED displays - Micro USB Connector (for Programming and Communication) - VGA Connector - External Connector Most other FPGA development boards come with just a simple connector but th= e Go Board has lots of functionality built right into it. The Kickstarter = page shows a bunch of examples of what is possible using the Nandland Go Bo= ard, and it's pretty impressive. You can even program it to play Pong! Ta= ke a look at the Kickstarter page and pick one up today. https://www.kickstarter.com/projects/1531311296/nandland-go-board-your-fpga= -playground?utm_source=3Ddirect&utm_medium=3Demail&utm_campaign=3Dkickstart= erArticle: 158435
There's a new FPGA development board on Kickstarter. It's called the Nandl= and Go Board, and it aims to be an inexpensive, easy-to-use FPGA developmen= t board to learn about how FPGAs work and what they are capable of. This b= oard is unique because it provides a lot of options for projects built dire= ctly into the board. It comes with:=20 - Four LEDs - Four Push-Button Switches - Two 7-Segment LED displays - Micro USB Connector (for Power, Programming, & Communication) - VGA Connector - External Connector Most other FPGA development boards come with just a simple connector but th= e Go Board has lots of functionality built right into it. The Kickstarter = page shows a bunch of examples of what is possible using the Nandland Go Bo= ard, and it's pretty impressive. You can even program it to play Pong! Ta= ke a look at the Kickstarter page and pick one up today. https://www.kickstarter.com/projects/1531311296/nandland-go-board-your-fpga= -playground?utm_source=3Dforum&utm_medium=3Dposting&utm_campaign=3Dkickstar= terArticle: 158436
I had a look at the datasheet at http://web.mit.edu/6.111/www/f2009/handouts/labs/ADV7125.pdf Maybe you also need to drive the "blank" pin, or the "psave".... It would pay to check the schematic...Article: 158437
Hello friends I have a fpga spartan-3 development board that only has a parallel port for JTAG. I used a parallel to usb cable and connected it to my laptop. When i connect the board to laptop, Windows says the drivers are installed successfully BUT when i lunch IMPACT and try 'initial chain' does not show my board. Is this because of parallel to usb cable? any help is appreciatedArticle: 158438
On 11/26/2015 2:09 AM, s.mohsen.shahabi@gmail.com wrote: > Hello friends > I have a fpga spartan-3 development board that only has a parallel port for JTAG. > I used a parallel to usb cable and connected it to my laptop. When i connect the board to laptop, Windows says the drivers are installed successfully BUT when i lunch IMPACT and try 'initial chain' does not show my board. > Is this because of parallel to usb cable? > any help is appreciated I don't have any first hand experience with these cables, but I have read often that they don't work very well with software that bit bangs the parallel port for JTAG support. Seems the virtual drivers get in the way and make it nearly impossible to control timing of the pins. USB to serial cables work a lot better. There are a number of low cost JTAG cables out there based on the FTDI serial port USB devices I believe. I see them on eBay, but have not tried any. -- RickArticle: 158439
So I have a partly-complete design for a 6502 CPU, it's simulating just fin= e for the implemented opcodes, but when I run synthesis, I get a whole load= of "Sequential element (\newSPData_reg[23] ) is unused and will be removed= from module execute.", one for each bit in the register, in fact. I know the logic is *trying* to use this register, I can see the values in = the register changing during simulation runs, but I can't for the life of m= e see why it would be removed - the 'execute' module is basically a case st= atement, with one of the cases explicitly setting the value of the 'newSPDa= ta' register. Again, in the simulation, I see the case being executed, and the values cha= nging. I guess what I'm looking for is any tips on how to tackle the proble= m ("The Knowledge", if you will), I've already tried the 'trace through the= logic for the case that should trigger the case in question, and see if an= ything jumps out at me'. I remain un-jumped-out-at [sigh]. I'm happy to send the design if anyone wants to have a look, but it's a chu= nk of verilog code, so didn't want to paste it here... Cheers Simon.Article: 158440
On 11/30/2015 1:27 AM, Simon wrote: > So I have a partly-complete design for a 6502 CPU, it's simulating just fine for the implemented opcodes, but when I run synthesis, I get a whole load of "Sequential element (\newSPData_reg[23] ) is unused and will be removed from module execute.", one for each bit in the register, in fact. > > I know the logic is *trying* to use this register, I can see the values in the register changing during simulation runs, but I can't for the life of me see why it would be removed - the 'execute' module is basically a case statement, with one of the cases explicitly setting the value of the 'newSPData' register. > > Again, in the simulation, I see the case being executed, and the values changing. I guess what I'm looking for is any tips on how to tackle the problem ("The Knowledge", if you will), I've already tried the 'trace through the logic for the case that should trigger the case in question, and see if anything jumps out at me'. I remain un-jumped-out-at [sigh]. > > I'm happy to send the design if anyone wants to have a look, but it's a chunk of verilog code, so didn't want to paste it here... Usually logic is removed because the result is not used anywhere. You can design and simulate a design only to see the synthesizer remove the entire thing if it has no outputs that make it to an I/O pin. So where are the outputs of your register used? Do they actually connect? -- RickArticle: 158441
On 30/11/2015 06:27, Simon wrote: > So I have a partly-complete design for a 6502 CPU, it's simulating just fine for the implemented opcodes, but when I run synthesis, I get a whole load of "Sequential element (\newSPData_reg[23] ) is unused and will be removed from module execute.", one for each bit in the register, in fact. > > I know the logic is *trying* to use this register, I can see the values in the register changing during simulation runs, but I can't for the life of me see why it would be removed - the 'execute' module is basically a case statement, with one of the cases explicitly setting the value of the 'newSPData' register. > > Again, in the simulation, I see the case being executed, and the values changing. I guess what I'm looking for is any tips on how to tackle the problem ("The Knowledge", if you will), I've already tried the 'trace through the logic for the case that should trigger the case in question, and see if anything jumps out at me'. I remain un-jumped-out-at [sigh]. > > I'm happy to send the design if anyone wants to have a look, but it's a chunk of verilog code, so didn't want to paste it here... > > Cheers > Simon. > Hi Simon, Before you spend a lot of time analysing the synthesis messages I would suggest you run a gate level simulation. If that fails then start looking at the gate level and warning/note messages. Synthesis tools are quite clever these days and it is not unusual for the synthesis tools to add/remove or merge registers. Good luck, Hans www.ht-lab.comArticle: 158442
On Sun, 29 Nov 2015 22:27:00 -0800, Simon wrote: > So I have a partly-complete design for a 6502 CPU, it's simulating just > fine for the implemented opcodes, but when I run synthesis, I get a > whole load of "Sequential element (\newSPData_reg[23] ) is unused and > will be removed from module execute.", one for each bit in the register, > in fact. > > I know the logic is *trying* to use this register, I can see the values > in the register changing during simulation runs, but I can't for the > life of me see why it would be removed - the 'execute' module is > basically a case statement, with one of the cases explicitly setting the > value of the 'newSPData' register. > > Again, in the simulation, I see the case being executed, and the values > changing. I guess what I'm looking for is any tips on how to tackle the > problem ("The Knowledge", if you will), I've already tried the 'trace > through the logic for the case that should trigger the case in question, > and see if anything jumps out at me'. I remain un-jumped-out-at [sigh]. > > I'm happy to send the design if anyone wants to have a look, but it's a > chunk of verilog code, so didn't want to paste it here... > > Cheers > Simon. Doesn't the 6502 have a 16-bit or smaller stack pointer? If so, maybe you've declared it bigger than it should be, and the synthesizer is trimming it to what's used? -- www.wescottdesign.comArticle: 158443
>I'm happy to send the design if anyone wants to have a look, but >it's a >chunk of verilog code, so didn't want to paste it here... > >Cheers > Simon. Thats why we have github.com Back probably before you were born somebody created an optimizing compiler that gave an incredible benchmark time until they realized that the benchmark did an huge amount of work to create a result but then never bothered to use it anywhere. All the code was optimised away. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158444
In article <450e997a-afd7-4c3d-a181-b324af6ede3c@googlegroups.com>, Simon <google@gornall.net> wrote: >So I have a partly-complete design for a 6502 CPU, it's simulating >just fine for the implemented opcodes, but when I run synthesis, I >get a whole load of "Sequential element (\newSPData_reg[23] ) is >unused and will be removed from module execute.", one for each bit >in the register, in fact. > >I know the logic is *trying* to use this register, I can see the values >in the register changing during simulation runs, but I can't for the >life of me see why it would be removed - the 'execute' module is >basically a case statement, with one of the cases explicitly setting >the value of the 'newSPData' register. > >Again, in the simulation, I see the case being executed, and the >values changing. I guess what I'm looking for is any tips on how to >tackle the problem ("The Knowledge", if you will), I've already >tried the 'trace through the logic for the case that should trigger >the case in question, and see if anything jumps out at me'. I >remain un-jumped-out-at [sigh]. <snip> Simon - just ignore the message and move on. Really. Synthesis optimizations are quite advanced these days - both combinatorial and across registers. Some sort of optimization that may not be obvious to you, may have combined your register bit with another, leaving this one "unused". It's ok. Trust the tool, and just move on. Regards, MarkArticle: 158445
Thanks for all the replies, guys :) On Sunday, November 29, 2015 at 11:51:03 PM UTC-8, rickman wrote: >=20 > Usually logic is removed because the result is not used anywhere. You=20 > can design and simulate a design only to see the synthesizer remove the= =20 > entire thing if it has no outputs that make it to an I/O pin. >=20 > So where are the outputs of your register used? Do they actually connect= ? Actually, this may be it. I had tried to counter this by exporting the data= bus (both input and output) in the top-level test-bench module, but thinkin= g about it, the registers it's removing are from code that exercises the BR= K instruction, which only affects the stack-pointer and program-counter, bo= th of which are internal to the CPU in the design as it stands, and the BRK= instruction is currently the only thing to manipulate the stack pointer (I= 'm going alphabetically through the instruction list, and I've only got as = far as EOR :) Sounds like a likely candidate for what the problem is. Presumably once oth= er things start to also reference the stack pointer (eg: PLA - pull accumul= ator from stack, where A is also linked to the data-bus via other instructi= ons) it will sort itself out. If this isn't the case, is there any sort of annotation/directive to say "k= eep this stuff, I need it!" - there used to be something in ISE in the synt= hesis directives, but I looked last night, and didn't see anything there in= Vivado 2015.4... On Monday, November 30, 2015 at 8:55:51 AM UTC-8, Tim Wescott wrote: >=20 > Doesn't the 6502 have a 16-bit or smaller stack pointer? If so, maybe=20 > you've declared it bigger than it should be, and the synthesizer is=20 > trimming it to what's used? If it were just the bits I know are being unused (the top 8), I'd be fine w= ith that :) The 'execute' module can push up to (currently, using the BRK i= nstruction) 3 bytes of data onto the stack. I had declared a 32-bit exporte= d register in the module to store these (as well as a 2-bit count register = to say how many bytes were waiting), and then the cpu core (once 'execute' = has had its way) gets to actually manipulate the stack pointer by transferr= ing data from the shared port to the actual stack. The problem was that all= 32 bits were being "optimized" away, even though BRK was definitely pushin= g 3 bytes into it. On Monday, November 30, 2015 at 10:26:13 AM UTC-8, Mark Curry wrote: >=20 > Simon - just ignore the message and move on. Really. > Synthesis optimizations are quite advanced these > days - both combinatorial and across registers. =20 >=20 > Some sort of optimization that may not be obvious to=20 > you, may have combined your register bit with another, > leaving this one "unused". It's ok. Trust the tool,=20 > and just move on. I see - this dovetails into what Rick is saying above - assuming I'm right = that things won't be able to be optimized away once all the instructions ar= e present.=20 I was just concerned that I was doing all this work, and at the end of the = day I'd have a "cpu" that didn't do very much :)=20 Thanks all, again :) SimonArticle: 158446
Simon <google@gornall.net> wrote: > Thanks for all the replies, guys :) > On Sunday, November 29, 2015 at 11:51:03 PM UTC-8, rickman wrote: >> Usually logic is removed because the result is not used anywhere. You >> can design and simulate a design only to see the synthesizer remove the >> entire thing if it has no outputs that make it to an I/O pin. (snip) > Actually, this may be it. I had tried to counter this by exporting > the databus (both input and output) in the top-level test-bench > module, but thinking about it, the registers it's removing are > from code that exercises the BRK instruction, which only affects > the stack-pointer and program-counter, both of which are internal > to the CPU in the design as it stands, and the BRK instruction > is currently the only thing to manipulate the stack pointer > (I'm going alphabetically through the instruction list, and > I've only got as far as EOR :) (snip) > If this isn't the case, is there any sort of annotation/directive > to say "keep this stuff, I need it!" - there used to be something > in ISE in the synthesis directives, but I looked last night, > and didn't see anything there in Vivado 2015.4... I believe so, but I haven't tried it. Sometimes I only want to know if a design will fit into a certain FPGA, and not actually do anything with it. In that case, I would not want to optimize things out. Most often, though, when something goes away, the optimizer is right and my design is wrong. It only takes a small mistake to propagate through and remove a lot of logic. I have had, at least once, all logic removed! -- glenArticle: 158447
jt_eaton <84408@fpgarelated> wrote: (snip) > Back probably before you were born somebody created an optimizing > compiler that gave an incredible benchmark time until they realized > that the benchmark did an huge amount of work to create a result but > then never bothered to use it anywhere. > All the code was optimised away. There are stories like that, but one I remember is where the code was not optimized away, but all done at compile time. Well, that means almost all optimized away. It was a Fortran benchmark that did complicated calculations using statement functions. Statement functions in Fortran are one line functions, used similar to the way #define is used in C, though at the time it was not usual for them to be expanded inline. The IBM OS/360 Fortran H compiler, from the 1960's, did expand them inline, and also did constant expression evaluation, unlike many other compilers. The resulting code printed out the constant. In the case of FPGAs, it might optimize down to a constant output, with no logic left. -- glenArticle: 158448
Mark Curry <gtwrek@sonic.net> wrote: > In article <450e997a-afd7-4c3d-a181-b324af6ede3c@googlegroups.com>, > Simon <google@gornall.net> wrote: >>So I have a partly-complete design for a 6502 CPU, it's simulating >>just fine for the implemented opcodes, but when I run synthesis, I >>get a whole load of "Sequential element (\newSPData_reg[23] ) is >>unused and will be removed from module execute.", one for each bit >>in the register, in fact. (snip) > Simon - just ignore the message and move on. Really. > Synthesis optimizations are quite advanced these > days - both combinatorial and across registers. Since he did the simulation, that is probably what he should do. Often enough, I test my designs in an FPGA, and optimizing out means the logic is wrong. One I remember was video display logic where the logic was wrong on the video output. Maybe an enable for a tristate output. The result then recursively eliminates logic from that point back, which was everthing except the sync generator. I think the messages are generated in the order that the constant signals are found, so start with the message that comes first. It will say that some signal is constant, often a flip-flop that has a constant output. Find out why. > Some sort of optimization that may not be obvious to > you, may have combined your register bit with another, > leaving this one "unused". It's ok. Trust the tool, > and just move on. Yes, combined registers are okay. -- glenArticle: 158449
On 11/30/2015 2:02 PM, Simon wrote: > Thanks for all the replies, guys :) > > On Sunday, November 29, 2015 at 11:51:03 PM UTC-8, rickman wrote: >> >> Usually logic is removed because the result is not used anywhere. >> You can design and simulate a design only to see the synthesizer >> remove the entire thing if it has no outputs that make it to an I/O >> pin. >> >> So where are the outputs of your register used? Do they actually >> connect? > > Actually, this may be it. I had tried to counter this by exporting > the databus (both input and output) in the top-level test-bench > module, but thinking about it, the registers it's removing are from > code that exercises the BRK instruction, which only affects the > stack-pointer and program-counter, both of which are internal to the > CPU in the design as it stands, and the BRK instruction is currently > the only thing to manipulate the stack pointer (I'm going > alphabetically through the instruction list, and I've only got as far > as EOR :) > > Sounds like a likely candidate for what the problem is. Presumably > once other things start to also reference the stack pointer (eg: PLA > - pull accumulator from stack, where A is also linked to the data-bus > via other instructions) it will sort itself out. I don't think you are grasping the situation. If the output of the register isn't connected to anything, you have no need for it, so it is removed. It does not matter if any other instructions use this register, if *any* one part of the design uses this register output, it won't be removed... unless that part of the design is also removed first. > If this isn't the case, is there any sort of annotation/directive to > say "keep this stuff, I need it!" - there used to be something in ISE > in the synthesis directives, but I looked last night, and didn't see > anything there in Vivado 2015.4... If the output of the register isn't being used by the design, why do you care if it remains? It can't impact any result the hardware can calculate. I think you still need to look at the code and figure out why the registers don't drive any inputs. Rick -- Rick
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