USB HxC Breadboard Version and a boat load of questions

[average_male]

Hello All (Jeff),

I put together a breadboard version of the USB HxC Floppy Emulator. I am not sure what I was more surprised with, the fact that it worked the first time it was powered up or that it worked it all.

During this exercise, a couple of questions came up and was wonder if someone (Jeff) could assist in answering them:

1) I used the pre-complied POF (pre-compiled JED to be more accurate) that came with the source code and all works well. However, using Quartus II 9.1 and the supplied project solution, I was able to get the project to compile but when flashing the CPLD the LED (LED1_not) simply lights up, stays lit and the emulator is not recognized by the host app.

Question is: Is the latest code posted or do I need to use Quartus II version 7.2 rather than 9.1?

2) As mentioned in 1), only the pre-compiled JED file works (I have two CPLDs, the Atmel-which works with pre-compiled code and the EPM7128SLC which doesn't work with the pre-compiled code; the LED3_not continues to flash very fast and the host app doesn't recognize the emulator).

Question is: Is there something I need to do differently when flashing the EPM7128SLC? Have you seen this issue before when "LED3_not" just flashes very fast?

3) When compiling the Quartus project, I often get errors relating to macrocells exceeding the limit of the device, which is 128. The project compiles and the status/results screen notes that 131 macrocells were used. Fiddling with it for a while I was able to get it to 127 macrocells, but not sure what I had done to correct this.

Question is:Have any of you come across this issue? If so, how do I compile the project so the fitter doesn't throw this error?

4) It seems that even though the USB version doesn't support write back to the floppy image, it does seem to (on one or two occasions) write to the SRAM (at least that is what I recall).

Question is: Given the macocell limits for this CPLD solution, was the primary push to develop on microcontrollers based on the fact that the writing/updating logic would not fit on this 128 CPLD device?



In closing, I'd really like to thank Jeff for making this version of the project available. It really allows one to get a grasp on the interworkings or a floppy drive.

-Moe

[Jeff]

Question is: Is the latest code posted or do I need to use Quartus II version 7.2 rather than 9.1?

I think that i made a try with the v8, but i don't remember about the v9.1...
Could you post the .pof you generate here with the 9.1 ?

Question is: Is there something I need to do differently when flashing the EPM7128SLC? Have you seen this issue before when "LED3_not" just flashes very fast?

Probably a timing/signal/breadboard related problem.

3) When compiling the Quartus project, I often get errors relating to macrocells exceeding the limit of the device, which is 128. The project compiles and the status/results screen notes that 131 macrocells were used. Fiddling with it for a while I was able to get it to 127 macrocells, but not sure what I had done to correct this.

Question is:Have any of you come across this issue? If so, how do I compile the project so the fitter doesn't throw this error?

Yes all the time during the development (a nightmare...), but the current code fit the 128 macrocell correctly.
Did you have change somenthing ? code ? pin? synthetis/fitter options ?

4) It seems that even though the USB version doesn't support write back to the floppy image, it does seem to (on one or two occasions) write to the SRAM (at least that is what I recall).

Question is: Given the macocell limits for this CPLD solution, was the primary push to develop on microcontrollers based on the fact that the writing/updating logic would not fit on this 128 CPLD device?

Developing this emulator with 128 macrocell was really a challange. i have also developed the write support on fpga board.
In fact this is mostly a cost problem. uC generaly less expensive.

[average_male]

Attached is the 9.1 compiled CPLD image. To get it to compile I did what the "Resource Optimazation Advisor" suggested (this is under Tools=>Advisor) in addition I went to "Assignments=>Remove Assignments and selected only check the 'Remove Obsolete Assignments'". Not sure what it was that did it, It compiled/fitted only I have rebooted and just tried to compile it after all the previous attempts failed to fit.

I get these warnings and thought they were just old file refrences that were not needed to compile the final image:
Warning: Can't analyze file -- file ../rtl/vhdl/PulseGenerator.vhd is missing
Warning: Can't analyze file -- file ../rtl/vhdl/Shifter.vhd is missing

And I have these warnings also:
Critical Warning (10920): VHDL Incomplete Partial Association warning at HxCFloppyEmu.vhd(231): port or argument "HEADTRACKPOSITION" has 1/8 unassociated elements
Warning: Output pins are stuck at VCC or GND
Warning (13410): Pin "SRAM_ADDR[13]" is stuck at GND
Warning (13410): Pin "SRAM_ADDR[14]" is stuck at GND
Warning: Timing Analysis does not support the analysis of latches as synchronous elements for the currently selected device family

Still trying to figure this out on my end.

Thanks,
Moe

[Jeff]

Attached is the 9.1 compiled CPLD image. To get it to compile I did what the "Resource Optimazation Advisor" suggested (this is under Tools=>Advisor) in addition I went to "Assignments=>Remove Assignments and selected only check the 'Remove Obsolete Assignments'". Not sure what it was that did it, It compiled/fitted only I have rebooted and just tried to compile it after all the previous attempts failed to fit.

I get these warnings and thought they were just old file refrences that were not needed to compile the final image:
Warning: Can't analyze file -- file ../rtl/vhdl/PulseGenerator.vhd is missing
Warning: Can't analyze file -- file ../rtl/vhdl/Shifter.vhd is missing

And I have these warnings also:
Critical Warning (10920): VHDL Incomplete Partial Association warning at HxCFloppyEmu.vhd(231): port or argument "HEADTRACKPOSITION" has 1/8 unassociated elements
Warning: Output pins are stuck at VCC or GND
Warning (13410): Pin "SRAM_ADDR[13]" is stuck at GND
Warning (13410): Pin "SRAM_ADDR[14]" is stuck at GND
Warning: Timing Analysis does not support the analysis of latches as synchronous elements for the currently selected device family

Still trying to figure this out on my end.

Thanks,
Moe

well the bitstream is different so there are a problem... and i didn't found any pinout assignement in the qsf file... you should have a look to the original qsf file.

[average_male]

Ah, ok, I guess those pins were considered Obsolete by Quartus...

Thanks for pointing that out, will look in that direction.

-Moe

[average_male]

Ok, so I restored the QSF file and then it didn't compile.

However, when commenting out just one of the LED signal assignments in the "HxCFloppyEmu.vhd" file, it compiles and fits fine. Results is the USB light flashing very fast. So I think you are correct when you stated its a breadboard config issue. But what gets me is that the Atmel CPLD works just fine.

Back to the drawing board.

-Moe

PS. This line of code was commented out: -- LED2_not<=not(step_led); -- step led

[Jeff]

PS. This line of code was commented out: -- LED2_not<=not(step_led); -- step led

What's the problem with this line ?

However, when commenting out just one of the LED signal assignments in the "HxCFloppyEmu.vhd" file, it compiles and fits fine. Results is the USB light flashing very fast. So I think you are correct when you stated its a breadboard config issue. But what gets me is that the Atmel CPLD works just fine.

The usb light should flashing when connected to the software... In fact each time that a packet is incoming the light is on.

[average_male]

Hi Jeff,

Commenting out this line:

"LED2_not<=not(step_led); -- step led"

allows the fitter to fit the bitstream onto the CPLD. otherwise it's a no-go. Seems the VHDL is a very tight fit for the CPLD. The result of commentting out that line out is that the LED2 stays on.

Regarding the USB light flashing, yes this LED is on whenever there is USB activity (wrtie to FTDI chip in this case). I had set up the Host App in debug mode and it seems that the CPLD never sends back any bytes to the Host App when expected. The "IF" statement below always returns 0 and Intialization always fails keeping us in the "do - while(init_failed);" loop:

File: usb_hxcfloppyemulator.c
Lines: 431-442

Code: Select all

			// on efface la SRAM de la carte
			memset(srambuffer,0x00,SRAMSIZE);
			write_ftdichip(hw_handle,srambuffer,SRAMSIZE);

			purge_ftdichip(hw_handle,FT_PURGE_RX);

			//memoire effacee -> la carte ne doit rien envoyer
			if(hxc_waitevent(floppycontext,1,400))                            //<=== FAIL to RX chars from CPLD
			{// ok on est parti en timeout
				//
				// maintenant on place une commande de synchro dans le buffer
				// et cette fois-ci la carte doit envoyer un octet regulierement

The event that was set up, namely, "FT_EVENT_RXCHAR" never seems to occur. I tried increasing the TIMEOUT value but still the method returns 0.

I had run into cases where the pins on the CPLD were pushed in too far and didn't contact the socket connectors, this doesn't seem to be the case as I pushed them all out to ensure they touched and ran 'Universal Scan' and LEDs to confirm.

I am going to get another MAX7000S CPLD and see if its a device issue. But it seems the device response to other tests, so not sure it that would provide any answers.

Thanks,
Moe

[Jeff]

Hi Jeff,

Commenting out this line:

"LED2_not<=not(step_led); -- step led"

allows the fitter to fit the bitstream onto the CPLD. otherwise it's a no-go. Seems the VHDL is a very tight fit for the CPLD. The result of commentting out that line out is that the LED2 stays on.

Regarding the USB light flashing, yes this LED is on whenever there is USB activity (wrtie to FTDI chip in this case). I had set up the Host App in debug mode and it seems that the CPLD never sends back any bytes to the Host App when expected. The "IF" statement below always returns 0 and Intialization always fails keeping us in the "do - while(init_failed);" loop:

File: usb_hxcfloppyemulator.c
Lines: 431-442

Code: Select all

			// on efface la SRAM de la carte
			memset(srambuffer,0x00,SRAMSIZE);
			write_ftdichip(hw_handle,srambuffer,SRAMSIZE);

			purge_ftdichip(hw_handle,FT_PURGE_RX);

			//memoire effacee -> la carte ne doit rien envoyer
			if(hxc_waitevent(floppycontext,1,400))                            //<=== FAIL to RX chars from CPLD
			{// ok on est parti en timeout
				//
				// maintenant on place une commande de synchro dans le buffer
				// et cette fois-ci la carte doit envoyer un octet regulierement

The event that was set up, namely, "FT_EVENT_RXCHAR" never seems to occur. I tried increasing the TIMEOUT value but still the method returns 0.

I had run into cases where the pins on the CPLD were pushed in too far and didn't contact the socket connectors, this doesn't seem to be the case as I pushed them all out to ensure they touched and ran 'Universal Scan' and LEDs to confirm.

I am going to get another MAX7000S CPLD and see if its a device issue. But it seems the device response to other tests, so not sure it that would provide any answers.

Thanks,
Moe

Well, the bitstream present on the website was used before many time and still used without problem. So i really think that this is an electrical problem.

[average_male]

For sure its not the bitstream and perhaps not the breadboard setup, as when I use POF2JED on that bitstream (*.POF) and put in my Atmel CPLD in the socket, all works just fine. So there may be something wrong with the MAX7000S or some minor difference in how it tollerates some supporting components (resistor, cap, timing)?

Another MAX7000S is on the way and should norrow down the issue.

Is there a way to "Erase" the MAX7000S? I did this for the Atmel and its working fine.

Thanks.

[average_male]

Well, got in the MAX7000S today, programmed it with a different DEV board. Same results.

So that leaves just two possible issues to look into:

1) The Software (Quartus II) programmer may have issue
2) Something not right with the breadboard (more likely this, but the Atmel CPLD has no issues and was programmed with AtmISP 6.7)

The adventure continues...

[Jeff]

Well, got in the MAX7000S today, programmed it with a different DEV board. Same results.

So that leaves just two possible issues to look into:

1) The Software (Quartus II) programmer may have issue
2) Something not right with the breadboard (more likely this, but the Atmel CPLD has no issues and was programmed with AtmISP 6.7)

The adventure continues...

Atmel Timing & Eletrical spec != Altera Timing & Eletrical spec

[average_male]

Atmel Timing & Eletrical spec != Altera Timing & Eletrical spec

This is true, but seems the difference is very minimal (this is my amature opinion). Looking at the differences, would this really be an issue?




I'll pull out my multi-meter and double check the values of the resistors and such. I had already double checked the wires, and they look good.

Thanks,
Moe

PS- The new forum layout is very nice.

[Jeff]

Try to "play" with the clock line length and/or with the ft245 control lines length.

[average_male]

Try to "play" with the clock line length and/or with the ft245 control lines length.

Jeff == Genius!!!

That worked!!!

First the FT245 data and controll lines were shortened ... sane results...
Then the Clock/Crystal line were shortened , same results...
Finally both the data and address lines for the SRAM were shortened and that worked!!!

One thing I did notice is that the Altera CPLD, even with the shortened lines, will have timing issues as it goes back into the USB blinking light sequence. This only happens maybe once every 20 minutes.

Is there anything I can do to make adjustments to the SRAM timing within the VHDL?

Thanks again Jeff,
Moe