Thread: [myhdl-list] Hello World
Brought to you by:
jandecaluwe
From: Günther S. <gue...@gm...> - 2015-04-25 18:12:36
|
Hello, i am quite new to Myhdl and playing around with the de0-nano Board. I was trying to access the ADXL345 over the SPI 3 wire bus. (just trying to read the DEVID) The small code example is working in simulation mode as far as i can judge. But on the real board i get 0x0 for the DEVID which should be 0xE5 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> import os import random from random import randrange from copy import copy ## python compile.py de0nano; cp altera/ise/stroby_de0nano/de0nano.qsf /home/tux/altera_proj/DE0_NANO_default ## python convert.py ; cp top.vhd pck_myhdl_081.vhd /home/tux/altera_proj/DE0_NANO_default ## python convert.py ; cp top.v tb_top.v /home/tux/altera_proj/DE0_NANO_default ## cp top.v top.v_orig; cp tb_top.v tb_top.v_orig; python convert.py ; cp top.v tb_top.v /home/tux/altera_proj/DE0_NANO_default; meld top.v top.v_orig; meld tb_top.v tb_top.v_orig; ## python gw.py; gtkwave test_dff.vcd ## pip install --upgrade git+https://github.com/jandecaluwe/myhdl from myhdl import * def clk_gen(CLOCK_50, tick, tick2): #CLK_FREQ = 48e6 # clock frequency #LED_RATE = 0.001 # strobe change rate CLK_FREQ = 10 # simulation only !!!! LED_RATE = 1 # simulation mode CNT_MAX = int(CLK_FREQ * LED_RATE) diff_rate = 0.45 CNT_DIFF = int(CLK_FREQ * diff_rate) clk_cnt = Signal(intbv(0, min=0, max=CNT_MAX+2)) @always(CLOCK_50.posedge) def logic(): clk_cnt.next = clk_cnt + 1 if clk_cnt == CNT_MAX-CNT_MAX/2: tick.next = 1 if clk_cnt == CNT_MAX-CNT_MAX/2+CNT_DIFF: tick2.next = 1 if clk_cnt == CNT_MAX: clk_cnt.next = 0 tick.next = 0 tick2.next = 0 return logic def readData(tick, tick2, G_SENSOR_CS_N,I2C_SDAT,LED , I2C_SCLK, count, START, PAUSE): w_adr_1 = Signal(intbv(0x8c)[8:0])#31-->31 w_data1 = Signal(intbv(0x02)[8:0])#40-->40 w_adr_2 = Signal(intbv(0x01)[8:0])#00-->80 r_data2 = Signal(intbv(0)[8:0]) # should be DEVID (0xE5) io = I2C_SDAT.driver() @always(tick.negedge) def readData_gen(): if count > 37+PAUSE: count.next = count -1 elif (count >=29+PAUSE) and (count <= 37+PAUSE) : count.next = count - 1 if (count >= 29+PAUSE) and (count <= 36+PAUSE): io.next = w_adr_1[36+PAUSE - count] elif (count >= 21+PAUSE) and (count < 29+PAUSE): count.next= count - 1 io.next = w_data1[28+PAUSE - count] elif (count >= 20) and (count < 21+PAUSE): count.next= count - 1 elif (count >= 11) and (count < 20): count.next = count - 1 if (count > 11) and (count <= 18): io.next = w_adr_2[18 - count] elif (count > 0) and (count < 11): count.next = count - 1 io.next = None else: count.next = START @always(tick2.posedge) def c_select(): if count == (45 + PAUSE): G_SENSOR_CS_N.next = 0 if count == (43 + PAUSE): G_SENSOR_CS_N.next = 1 if count == (36 + PAUSE): G_SENSOR_CS_N.next = 0 if count == (20 + PAUSE): G_SENSOR_CS_N.next = 1 if count == 18 : G_SENSOR_CS_N.next = 0 if count == 2 : G_SENSOR_CS_N.next = 1 if (count > 2) and (count < 11): if (I2C_SDAT == True): r_data2.next[10-count] = 1 else: r_data2.next[10-count] = 0 collector = Signal(intbv(0)[8:0]) @always_comb def check_sclk2(): if I2C_SDAT == 1: collector.next[0] = 1 else: collector.next[0] = 0 if I2C_SCLK == 1: collector.next[1] = 1 else: collector.next[1] = 0 if G_SENSOR_CS_N == 1: collector.next[2] = 0 else: collector.next[2] = 1 ################################# if count == 36+PAUSE: collector.next[7] = 1 else: collector.next[7] = 0 if count == 28+PAUSE: collector.next[6] = 1 else: collector.next[6] = 0 if count == 18: collector.next[5] = 1 else: collector.next[5] = 0 if count <=9 and count >=2: collector.next[4] = 1 else: collector.next[4] = 0 @always_comb def collector_comb(): LED.next = r_data2 #LED.next = collector return instances() def drive_spi(tick, tick2, G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT, LED, count, START, PAUSE): read_Adr_inst = readData( tick, tick2, G_SENSOR_CS_N,I2C_SDAT,LED , I2C_SCLK,count, START, PAUSE) @always_comb def al_c1(): I2C_SCLK.next = tick return instances() def top( CLOCK_50, LED,G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT): tick = Signal(False) tick2 = Signal(False) START = 40 PAUSE = 4 count = Signal(intbv(START, min=-1, max=10000)) clk_gen_inst = clk_gen(CLOCK_50, tick, tick2) drive_spi_inst = drive_spi(tick, tick2, G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT, LED, count, START, PAUSE) return instances() def test_dff(): G_SENSOR_CS_N = Signal(bool(1)) G_SENSOR_INT = Signal(bool(0)) I2C_SCLK = Signal(bool(1)) I2C_SDAT = TristateSignal(False) LED = Signal(intbv(0)[8:]) clk = Signal(bool(0)) dff_inst = top( clk, LED,G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT) @always(delay(1)) def clkgen(): clk.next = not clk return dff_inst, clkgen def simulate(timesteps): tb = traceSignals(test_dff) sim = Simulation(tb) sim.run(timesteps) simulate(4000) ######################################################## main.py: from myhdl import * from gw import top def convert(): G_SENSOR_CS_N = Signal(bool(1)) G_SENSOR_INT = Signal(bool(0)) I2C_SCLK = Signal(bool(1)) I2C_SDAT = TristateSignal(False) CLOCK_50 = Signal(bool(0)) LED = Signal(intbv(0)[8:]) ## toVerilog(top,clock,reset,LED) ## toVHDL(top,CLOCK_50, LED,G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT ) toVerilog(top,CLOCK_50, LED,G_SENSOR_CS_N,G_SENSOR_INT,I2C_SCLK,I2C_SDAT ) if __name__ == '__main__': convert() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I could not see any errors whan i look on the gtkwave signal. Mybe somebody has the same eval board and is somewhat familiar with the SPI. My guess is, that i am doing something wrong with the tristate signal I2C_SDAT ! Could this be the reason that a still have 0x0 instead of 0xE5 when i read this port? I would very much appreciate if someone could help me out because i really like myhdl a lot even i have not seen al lot of this tooling. Thank you very much. -- Mit freundlichen Grüßen Günther Stangassinger |
From: Christopher F. <chr...@gm...> - 2015-04-25 21:26:50
|
On 4/25/15 1:12 PM, Günther Stangassinger wrote: > Hello, > i am quite new to Myhdl and playing around with the de0-nano Board. > I was trying to access the ADXL345 over the SPI 3 wire bus. (just > trying to read the DEVID) > The small code example is working in simulation mode as far as i can judge. > But on the real board i get 0x0 for the DEVID which should be 0xE5 Is this the latest DE0 with the cyclone-IV? If you are intending to communicate over I2C are you keeping the CSn signal high to the ADXL345? (I have dug through the code yet). If you are not Do you have this in a public repo, like github or bitbucket? Regards, Chris |
From: Günther S. <gue...@gm...> - 2015-04-26 05:06:56
|
Thank you for your quick response. Yes it is the latest board with cyclone-IV No, i am communicating over SPI. This is just the port name wich has I2C in the name. I am sorry it is not in a github. I think it is just to small. The point is, i am not shure if i am using the tristate signal wich i call "io" in a correct way. When i look at the simulation, then i have according to the altera documentation: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/de0_nano_user_manual_v1.9.pdf the adress 0x31 set with the value 0x40 after that i am trying to read the DEVID from the adress 0x00 which is 0x80 because i am setting the read-bit in the SPI-3 wire mode. after that at the position for reading the DEVID is according to the simulation in a NONE Value of the tristate port. So it is looking ok for me, but there is some error. Mybe i am not using the tristate signal in a correct way. If you could tell me if the tristate signal looks ok in myhdl - way than it would help me a lot, than i would guess, that i still miss something in the SPI communication. Than you very much. ;-)guenther Am 25.04.2015 um 23:26 schrieb Christopher Felton: > On 4/25/15 1:12 PM, Günther Stangassinger wrote: >> Hello, >> i am quite new to Myhdl and playing around with the de0-nano Board. >> I was trying to access the ADXL345 over the SPI 3 wire bus. (just >> trying to read the DEVID) >> The small code example is working in simulation mode as far as i can judge. >> But on the real board i get 0x0 for the DEVID which should be 0xE5 > Is this the latest DE0 with the cyclone-IV? > > If you are intending to communicate over I2C are > you keeping the CSn signal high to the ADXL345? > (I have dug through the code yet). If you are > not > > Do you have this in a public repo, like github > or bitbucket? > > Regards, > Chris > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Mit freundlichen Grüßen Günther Stangassinger |
From: Christopher F. <chr...@gm...> - 2015-04-26 13:13:43
|
On 4/26/15 12:06 AM, Günther Stangassinger wrote: > Thank you for your quick response. > Yes it is the latest board with cyclone-IV > No, i am communicating over SPI. If you are using SPI you do not need a tristate, only I2C requires a tri-state for the SDA bi-direction (usually don't need one for SCL). If you are using SPI I would remove the tristate. Make sure the CSn signal goes low, didn't review the data sheet fully, don't know if it can be tied low or if it needs the transition. Regards, Chris |
From: Günther S. <gue...@gm...> - 2015-04-26 15:46:00
|
Are you sure? This is not a 4-Wire SPI. It is a 3 wire SPI. For a 4 wire there are extra ports for reading and writing, but with 3-wire the SDIO-port has the possibility to set a read or a write bit from the accelerometer wich is described here: http://www.geeetech.com/Documents/ADXL345%20Datasheet.pdf And this SDIO-port of the accelerometer is connected with I2C_SDAT of the Altera CyclonIV The problem is, that i do not know wheater i am doing something wrong with the bite sequences, which get into the accelerometer. So i whould very much appreciate, if someone could just run the simulation and take a look at the bitsequence in gtkwave and say if this bit sequence is making sense at all, or i am doing something really strange here? Thank you very much. Regards, guenther Am 26.04.2015 um 15:13 schrieb Christopher Felton: > On 4/26/15 12:06 AM, Günther Stangassinger wrote: >> Thank you for your quick response. >> Yes it is the latest board with cyclone-IV >> No, i am communicating over SPI. > If you are using SPI you do not need a tristate, > only I2C requires a tri-state for the SDA bi-direction > (usually don't need one for SCL). > > If you are using SPI I would remove the tristate. > Make sure the CSn signal goes low, didn't review > the data sheet fully, don't know if it can be tied > low or if it needs the transition. > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Christopher F. <chr...@gm...> - 2015-04-26 18:13:13
|
On 4/26/15 10:45 AM, Günther Stangassinger wrote: > Are you sure? No, I am not sure. I am not familiar with 3 wire SPI (seems odd) and when I looked at the datasheet, quickly ... > This is not a 4-Wire SPI. It is a 3 wire SPI. > For a 4 wire there are extra ports for reading and writing, > but with 3-wire the SDIO-port has the possibility to set a read or a > write bit > from the accelerometer wich is described here: > http://www.geeetech.com/Documents/ADXL345%20Datasheet.pdf > And this SDIO-port of the accelerometer is connected with I2C_SDAT of > the Altera CyclonIV I see (now) that the DE board is only connected to support 3-wire SPI or I2C, as you indicated: http://www.terasic.com/downloads/cd-rom/de0-nano/ I agree, the tristate is required. > The problem is, that i do not know wheater i am doing something wrong > with the > bite sequences, which get into the accelerometer. > So i whould very much appreciate, if someone could > just run the simulation and take a look at the bitsequence in > gtkwave and say if this bit sequence is making sense at all, > or i am doing something really strange here? I ran you code, something to try is only enable the clock during a valid transaction, when CSn is low, don't use a free running clock, as shown in figure 39: http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf Digging through the complete SPI transaction requires more time than I have right now. Regards, Chris |
From: Günther S. <gue...@gm...> - 2015-04-27 05:17:44
|
Thank you very much for your hint. I was trying this. The clock ist now running only when CSn is low. But without success. :-( There is still 0x0 as out put. Does anybody else have any hints? If you are saying the Tristatesignal is looking ok, than mybe i should focus on the sequence to read the DEVID. Thank you very much. Regards, guenther Am 26.04.2015 um 20:12 schrieb Christopher Felton: > On 4/26/15 10:45 AM, Günther Stangassinger wrote: >> Are you sure? > No, I am not sure. I am not familiar with 3 wire > SPI (seems odd) and when I looked at the datasheet, > quickly ... > >> This is not a 4-Wire SPI. It is a 3 wire SPI. >> For a 4 wire there are extra ports for reading and writing, >> but with 3-wire the SDIO-port has the possibility to set a read or a >> write bit >> from the accelerometer wich is described here: >> http://www.geeetech.com/Documents/ADXL345%20Datasheet.pdf >> And this SDIO-port of the accelerometer is connected with I2C_SDAT of >> the Altera CyclonIV > I see (now) that the DE board is only connected > to support 3-wire SPI or I2C, as you indicated: > http://www.terasic.com/downloads/cd-rom/de0-nano/ > > I agree, the tristate is required. > >> The problem is, that i do not know wheater i am doing something wrong >> with the >> bite sequences, which get into the accelerometer. >> So i whould very much appreciate, if someone could >> just run the simulation and take a look at the bitsequence in >> gtkwave and say if this bit sequence is making sense at all, >> or i am doing something really strange here? > I ran you code, something to try is only enable > the clock during a valid transaction, when CSn is > low, don't use a free running clock, as shown in > figure 39: > http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf > > Digging through the complete SPI transaction requires > more time than I have right now. > > Regards, > Chris > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Christopher F. <chr...@gm...> - 2015-04-27 12:39:19
|
On 4/27/2015 12:17 AM, Günther Stangassinger wrote: > Thank you very much for your hint. > I was trying this. > The clock ist now running only when CSn is low. > But without success. :-( > There is still 0x0 as out put. > Does anybody else have any hints? There are some changes you should make, in this design you should only have a single clock for the internal logic. The DEnano has a 50MHz clock, this should be the clock driving all your processes/generators. Don't use the generated SCLK to clock any internal logic. Then create posedge and negedge strobes based on the slower clock (or you can do it vise-versa have state machine that creates the edge strobes and the clock generated from there). Here is an example: https://bitbucket.org/cfelton/examples/src/tip/mycores/aic23/aic23_spi.py?at=default#cl-96 http://www.fpgarelated.com/showarticle/41.php > If you are saying the Tristatesignal is looking ok, > than mybe i should focus on the sequence to read the DEVID. > Thank you very much. The tristate looks ok in the simulation (not fully decoding the bus transaction). Personally I would break out the when/how the tristate is driven to a separate process/generator: bitout = Signal(bool(0)) io = I2C_SDAT.driver() # .... @always_comb def tristate_driver(): if count > 0 and count < 11: io.next = None else: io.next = bitout Only the tristate is the output of this process. This shouldn't functionally change your code but in the converted code you will have a simple expression for the tristate. Regards, Chris |
From: Christopher F. <chr...@gm...> - 2015-04-27 18:21:06
|
Gunther, I put together a simple ADXL345 3-wire SPI model, this might give you something to play with and test. https://gist.github.com/cfelton/2a0106edc5bd2b1bec4c In your test_dff add: mdl = ADXL345() gmdl = mdl.process(I2C_SCLK, I2C_SDAT, G_SENSOR_CS_N, G_SENSOR_INT) Don't forget to add `gmdl` to the return list. I also added this around line 92 to "emulate" a pullup (for simulation only): # emulate a pullup sdati = Signal(bool(0)) def _pullup(I2C_SDAT, sdati): @always_comb def emupull(): if I2C_SDAT == None: sdati.next = True else: sdati.next = False return emupull _pullup.verilog_code = 'assign $sdati = $I2C_SDAT' gpull = _pullup(I2C_SDAT, sdati) Regards, Chris On 4/27/2015 7:38 AM, Christopher Felton wrote: > On 4/27/2015 12:17 AM, Günther Stangassinger wrote: >> Thank you very much for your hint. >> I was trying this. >> The clock ist now running only when CSn is low. >> But without success. :-( >> There is still 0x0 as out put. >> Does anybody else have any hints? > > There are some changes you should make, in this design > you should only have a single clock for the internal > logic. The DEnano has a 50MHz clock, this should be > the clock driving all your processes/generators. Don't > use the generated SCLK to clock any internal logic. > > Then create posedge and negedge strobes based on the > slower clock (or you can do it vise-versa have state > machine that creates the edge strobes and the clock > generated from there). > > Here is an example: > https://bitbucket.org/cfelton/examples/src/tip/mycores/aic23/aic23_spi.py?at=default#cl-96 > http://www.fpgarelated.com/showarticle/41.php > >> If you are saying the Tristatesignal is looking ok, >> than mybe i should focus on the sequence to read the DEVID. >> Thank you very much. > > The tristate looks ok in the simulation (not fully > decoding the bus transaction). Personally I would > break out the when/how the tristate is driven to > a separate process/generator: > > bitout = Signal(bool(0)) > io = I2C_SDAT.driver() > > # .... > > @always_comb > def tristate_driver(): > if count > 0 and count < 11: > io.next = None > else: > io.next = bitout > > Only the tristate is the output of this process. > This shouldn't functionally change your code but in > the converted code you will have a simple expression > for the tristate. > > Regards, > Chris > |
From: Christopher F. <chr...@gm...> - 2015-04-27 20:49:21
|
On 4/27/2015 7:38 AM, Christopher Felton wrote: > On 4/27/2015 12:17 AM, Günther Stangassinger wrote: >> Thank you very much for your hint. >> I was trying this. >> The clock ist now running only when CSn is low. >> But without success. :-( >> There is still 0x0 as out put. >> Does anybody else have any hints? > > There are some changes you should make, in this design > you should only have a single clock for the internal > logic. The DEnano has a 50MHz clock, this should be > the clock driving all your processes/generators. Don't > use the generated SCLK to clock any internal logic. > Warning like the following should be fixed, remove `tick` and `tick2` as clocks and only use `CLOCK_50` as a clock: Warning (332060): Node: tick was determined to be a clock but was found without an associated clock assignment. Warning (332060): Node: tick2 was determined to be a clock but was found without an associated clock assignment. Regards, Chris |
From: Günther S. <gue...@gm...> - 2015-05-21 10:20:46
|
Hello Christopher, you wrote: "The DEnano has a 50MHz clock, this should be the clock driving all your processes/generators. Don't use the generated SCLK to clock any internal logic." Can you please tell me the reason for this? Because obviously it is working with when i use the generated SCLK Is it because of timing issues or are there any other reasons? I saw in your example that you are using posedge and negedge. But the frequency of the system clock is so much higher than the frequency i am working with, so does it matter if i use posedge and in another process negedge. So i could combine all together in only for example posedge. Or did i get something wrong? Thank you. Regards guenther On 27.04.2015 14:38, Christopher Felton wrote: > On 4/27/2015 12:17 AM, Günther Stangassinger wrote: >> Thank you very much for your hint. >> I was trying this. >> The clock ist now running only when CSn is low. >> But without success. :-( >> There is still 0x0 as out put. >> Does anybody else have any hints? > There are some changes you should make, in this design > you should only have a single clock for the internal > logic. The DEnano has a 50MHz clock, this should be > the clock driving all your processes/generators. Don't > use the generated SCLK to clock any internal logic. > > Then create posedge and negedge strobes based on the > slower clock (or you can do it vise-versa have state > machine that creates the edge strobes and the clock > generated from there). > > Here is an example: > https://bitbucket.org/cfelton/examples/src/tip/mycores/aic23/aic23_spi.py?at=default#cl-96 > http://www.fpgarelated.com/showarticle/41.php > >> If you are saying the Tristatesignal is looking ok, >> than mybe i should focus on the sequence to read the DEVID. >> Thank you very much. > The tristate looks ok in the simulation (not fully > decoding the bus transaction). Personally I would > break out the when/how the tristate is driven to > a separate process/generator: > > bitout = Signal(bool(0)) > io = I2C_SDAT.driver() > > # .... > > @always_comb > def tristate_driver(): > if count > 0 and count < 11: > io.next = None > else: > io.next = bitout > > Only the tristate is the output of this process. > This shouldn't functionally change your code but in > the converted code you will have a simple expression > for the tristate. > > Regards, > Chris > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Mit freundlichen Grüßen Günther Stangassinger |
From: Christopher F. <chr...@gm...> - 2015-05-26 15:00:21
|
On 5/21/2015 5:20 AM, Günther Stangassinger wrote: > Hello Christopher, > you wrote: > > "The DEnano has a 50MHz clock, this should be > the clock driving all your processes/generators. Don't > use the generated SCLK to clock any internal logic." > > > Can you please tell me the reason for this? It is going to be the safest design practice and the easiest to guarantee you have met timing. Even with slow clocks it is best to use a single clock and a single edge in most cases (there are always exceptions). The Altera Quartus synthesis guide is a reasonable reference and will do a better job describing the pitfalls than I would in a short response. See section "Synchronous FPGA Design Practices" on page12-2 in the following document and specifically "Clocking Schemes" on page 12-7. https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/qts/qts_qii51006.pdf Hope that helps, Chris |
From: Günther S. <gue...@gm...> - 2015-05-28 21:29:47
|
Hi Christopher, Now i rewrote my code with only the system clock in the process, and i do not have any timing issues anymore. Now i can run the 3wire SPI with 1 MHz and get the correct DEVID of the accelerometer. i checked in my code: https://github.com/stangassinger/de0_nano_adxl345 Thanks a lot. Regards guenther Am 26.05.2015 um 16:59 schrieb Christopher Felton: > On 5/21/2015 5:20 AM, Günther Stangassinger wrote: >> Hello Christopher, >> you wrote: >> >> "The DEnano has a 50MHz clock, this should be >> the clock driving all your processes/generators. Don't >> use the generated SCLK to clock any internal logic." >> >> >> Can you please tell me the reason for this? > It is going to be the safest design practice and > the easiest to guarantee you have met timing. Even > with slow clocks it is best to use a single clock > and a single edge in most cases (there are always > exceptions). > > The Altera Quartus synthesis guide is a reasonable > reference and will do a better job describing the > pitfalls than I would in a short response. > > See section "Synchronous FPGA Design Practices" on > page12-2 in the following document and specifically > "Clocking Schemes" on page 12-7. > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/qts/qts_qii51006.pdf > > Hope that helps, > Chris > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Günther S. <gue...@gm...> - 2015-05-15 08:53:59
|
Hello together, unfortunatelly i was not really successfull with my ADXL345 reading the DEVID with de0-nano I managed to get the same sequence in simulation as someone who was doing the same here: http://www.mikrocontroller.net/topic/350597 At the bottom you can see sequences which are quite the same, as what i get when i run my code in simulation with python gw.py I have my code here now: https://github.com/stangassinger/de0_nano_adxl345 So if someone has also a de0-nano board, it would be great if he could test it on his board. So i am quite pleased with the output in simulation mode.(Also the expected tristate signal is on the right position!) But when i run the converted verilog code on my de0-nano i only get 0x0 as the output instead of 0xE5 So any hints for this, mybe very small problem are very wellcome. Until now i am very convinced of myhdl but i want to transfer it to real word problems. Thank you very much. -- Best Regards Günther Stangassinger |
From: Günther S. <gue...@gm...> - 2015-05-16 18:27:29
|
Hello, it is working: https://github.com/stangassinger/de0_nano_adxl345 I am getting the DEVID 0xE5 The problem was not the myhdl code. The problem was the generated verilog code. At the beginning of the generated code where the ports are declared it says: output I2C_SDAT; And this was one and only problem !! Because the I2C_SDAT is tristate it should not be a output port. There fore i changed it to: inout I2C_SDAT; And with this change it is working :-) :-) But my question now is: How do i have to declare the I2C_SDAT port in myhdl so that it generates to "inout" ??? I declared it with: I2C_SDAT = TristateSignal(False) What do i have to do the it generates this code: inout I2C_SDAT; I would be very glad if someone could help me? Thank you very much. Best regards guenther stangassinger Am 15.05.2015 um 10:53 schrieb Günther Stangassinger: > Hello together, > unfortunatelly i was not really successfull with my ADXL345 reading the > DEVID with de0-nano > I managed to get the same sequence in simulation as someone who was > doing the same here: > http://www.mikrocontroller.net/topic/350597 > At the bottom you can see sequences which are quite the same, as what i get > when i run my code in simulation with > python gw.py > I have my code here now: > https://github.com/stangassinger/de0_nano_adxl345 > > So if someone has also a de0-nano board, it would be great if he could > test it on his board. > > So i am quite pleased with the output in simulation mode.(Also the > expected tristate signal is on the right position!) > But when i run the converted verilog code on my de0-nano > i only get 0x0 as the output instead of 0xE5 > > So any hints for this, mybe very small problem are very wellcome. > > Until now i am very convinced of myhdl but i want to transfer it to real > word problems. > Thank you very much. > -- Mit freundlichen Grüßen Günther Stangassinger |
From: Josy B. <jos...@gm...> - 2015-05-17 10:54:18
|
Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > > Hello, > it is working: > https://github.com/stangassinger/de0_nano_adxl345 > I am getting the DEVID 0xE5 > The problem was not the myhdl code. > The problem was the generated verilog code. > At the beginning of the generated code where the ports are declared > it says: > output I2C_SDAT; > > And this was one and only problem !! > Because the I2C_SDAT is tristate it should not be a output port. > There fore i changed it to: > inout I2C_SDAT; > > And with this change it is working > > But my question now is: > How do i have to declare the I2C_SDAT port in myhdl > so that it generates to "inout" ??? > > I declared it with: > > I2C_SDAT = TristateSignal(False) > > What do i have to do the it generates this code: > inout I2C_SDAT; > > I would be very glad if someone could help me? > Thank you very much. > Best regards > guenther stangassinger > Hallo Günther, I converted your code to VHDL and there we get an *inout* for I2C_SDAT. But there is one error though: we get : drive_spi_inst_read_Adr_inst_io <= (others => 'Z'); where it should be: drive_spi_inst_read_Adr_inst_io <= 'Z'; I suggest you make an issue out of it as the conversion of TristateSignal doesn't look to be error-free. Personally I avoid (read: don't use at all) internal tristate signals: my I2C modules have a separate input and output signal for SDa, which I then drive to the SDa pin via an **opendrain** primitive in the toplevel file. Regards, Josy |
From: Günther S. <gue...@gm...> - 2015-05-17 11:27:26
|
Hello Josy, thank you. yes i saw that in VHDL there was this error. Therefore i tried it with verilog. But what i really do not understand what you mean you do not use read at all. Can you please explain this to me? When i have this: I2C_SDAT = TristateSignal(False) How would i have to write it to avoid this and how can i use this opendrain primitive than?? -- Regards guenther Am 17.05.2015 um 12:53 schrieb Josy Boelen: > Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > >> Hello, >> it is working: >> https://github.com/stangassinger/de0_nano_adxl345 >> I am getting the DEVID 0xE5 >> The problem was not the myhdl code. >> The problem was the generated verilog code. >> At the beginning of the generated code where the ports are declared >> it says: >> output I2C_SDAT; >> >> And this was one and only problem !! >> Because the I2C_SDAT is tristate it should not be a output port. >> There fore i changed it to: >> inout I2C_SDAT; >> >> And with this change it is working >> >> But my question now is: >> How do i have to declare the I2C_SDAT port in myhdl >> so that it generates to "inout" ??? >> >> I declared it with: >> >> I2C_SDAT = TristateSignal(False) >> >> What do i have to do the it generates this code: >> inout I2C_SDAT; >> >> I would be very glad if someone could help me? >> Thank you very much. >> Best regards >> guenther stangassinger >> > Hallo Günther, > > I converted your code to VHDL and there we get an *inout* for I2C_SDAT. > But there is one error though: > we get : drive_spi_inst_read_Adr_inst_io <= (others => 'Z'); > where it should be: drive_spi_inst_read_Adr_inst_io <= 'Z'; > > I suggest you make an issue out of it as the conversion of > TristateSignal doesn't look to be error-free. > > Personally I avoid (read: don't use at all) internal tristate signals: > my I2C modules have a separate input and output signal for SDa, which I > then drive to the SDa pin via an **opendrain** primitive in the toplevel > file. > > Regards, > > Josy > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Josy B. <jos...@gm...> - 2015-05-17 18:13:50
|
Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > > Hello Josy, > thank you. > yes i saw that in VHDL there was this error. > Therefore i tried it with verilog. > But what i really do not understand what you mean you > do not use read at all. > Can you please explain this to me? > When i have this: > > I2C_SDAT = TristateSignal(False) > > How would i have to write it to avoid this and > how can i use this opendrain primitive than?? > Hello Günther, The one essential part of my answer was that the conversion of TristateSignal() seems to be incorrect, both for Verilog and VHDL. Also the VHDL conversion gives quite a few warnings: ** ToVHDLWarning: Output port is read internally: G_SENSOR_CS_N ** ToVHDLWarning: Port is not used: G_SENSOR_INT ** ToVHDLWarning: Output port is read internally: I2C_SCLK ** ToVHDLWarning: Output port is read internally: I2C_SDAT ** ToVHDLWarning: Signal is driven but not read: drive_spi_inst_read_Adr_inst_r_data2 ** ToVHDLWarning: Signal is driven but not read: drive_spi_inst_read_Adr_inst_io ** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_data1 ** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_adr_2 ** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_adr_1 Some of them are benign, some of them are to avoid. Not that I am converting your code as you posted yesterday. 1. ** ToVHDLWarning: Output port is read internally: G_SENSOR_CS_N This is (very probably) not your intention, and will (in VHDL) produce an *inout* port in stead of an *out* port. You can correct that by using local signals and assign the output port in a separate combinatorial procress. 2.** ToVHDLWarning: Port is not used: G_SENSOR_INT You actually are not using it. 3.** ToVHDLWarning: Output port is read internally: I2C_SCLK This is like 1. 4.** ToVHDLWarning: Output port is read internally: I2C_SDAT For a top-level module this can't be easily avoided. Note that in a VHDL top-file we would use a primitive like this: -- drive SDa via an open drain primitive od1 : opndrn port map(qs_SdaOut, IfSDa); which would be warning-free 5.** ToVHDLWarning: Signal is driven but not read: drive_spi_inst_read_Adr_inst_r_data2 6.** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_data1 ** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_adr_2 ** ToVHDLWarning: Signal is not driven: drive_spi_inst_read_Adr_inst_w_adr_1 I'm not sure whether these three warnings should be there at all. You are using a Signal(intbv() as a constant. The generated VHDL is correct. The warning is correct though in stating that the Signal is not driven, read: depending on an input port. Perhaps I shouldn't have mentioned my preference of splitting opendrain and tristate signals into inputs, outputs and for the tristate enable. Now for your gw.py file this is no solution either as I understood that you are using the converted result as the top-file in your Quartus II project. Regards, Josy |
From: Günther S. <gue...@gm...> - 2015-05-17 18:55:11
|
Hello Josy, thank you for your answer. My problem is that i have to modify the generated verilog(vhdl) code to make it work. Is myhdl meant to be like this or do i just have bad luck with this example? I am asking because i am very new to myhdl and this is acually my second example what i was trying. Are you doing large projects with myhdl? I am asking because i want to know if i should dig more into myhdl or should i focus more on vhdl, when i do have to modify vhdl afterwards anyway. So what is your experiance? -- Regards guenther Am 17.05.2015 um 20:13 schrieb Josy Boelen: > Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > >> Hello Josy, >> thank you. >> yes i saw that in VHDL there was this error. >> Therefore i tried it with verilog. >> But what i really do not understand what you mean you >> do not use read at all. >> Can you please explain this to me? >> When i have this: >> >> I2C_SDAT = TristateSignal(False) >> >> How would i have to write it to avoid this and >> how can i use this opendrain primitive than?? >> > Hello Günther, > > The one essential part of my answer was that the conversion of > TristateSignal() seems to be incorrect, both for Verilog and VHDL. > Also the VHDL conversion gives quite a few warnings: > ** ToVHDLWarning: Output port is read internally: G_SENSOR_CS_N > ** ToVHDLWarning: Port is not used: G_SENSOR_INT > ** ToVHDLWarning: Output port is read internally: I2C_SCLK > ** ToVHDLWarning: Output port is read internally: I2C_SDAT > ** ToVHDLWarning: Signal is driven but not read: > drive_spi_inst_read_Adr_inst_r_data2 > ** ToVHDLWarning: Signal is driven but not read: > drive_spi_inst_read_Adr_inst_io > ** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_data1 > ** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_adr_2 > ** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_adr_1 > > Some of them are benign, some of them are to avoid. > Not that I am converting your code as you posted yesterday. > 1. ** ToVHDLWarning: Output port is read internally: G_SENSOR_CS_N > This is (very probably) not your intention, and will (in VHDL) produce > an *inout* port in stead of an *out* port. You can correct that by using > local signals and assign the output port in a separate combinatorial > procress. > > 2.** ToVHDLWarning: Port is not used: G_SENSOR_INT > You actually are not using it. > > 3.** ToVHDLWarning: Output port is read internally: I2C_SCLK > This is like 1. > > 4.** ToVHDLWarning: Output port is read internally: I2C_SDAT > For a top-level module this can't be easily avoided. Note that in a VHDL > top-file we would use a primitive like this: > -- drive SDa via an open drain primitive > od1 : opndrn port map(qs_SdaOut, IfSDa); > which would be warning-free > > 5.** ToVHDLWarning: Signal is driven but not read: > drive_spi_inst_read_Adr_inst_r_data2 > > 6.** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_data1 > ** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_adr_2 > ** ToVHDLWarning: Signal is not driven: > drive_spi_inst_read_Adr_inst_w_adr_1 > I'm not sure whether these three warnings should be there at all. You > are using a Signal(intbv() as a constant. The generated VHDL is correct. > The warning is correct though in stating that the Signal is not driven, > read: depending on an input port. > > Perhaps I shouldn't have mentioned my preference of splitting opendrain > and tristate signals into inputs, outputs and for the tristate enable. > Now for your gw.py file this is no solution either as I understood that > you are using the converted result as the top-file in your Quartus II > project. > > > Regards, > > Josy > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Josy B. <jos...@gm...> - 2015-05-17 19:25:32
|
Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > > Hello Josy, > thank you for your answer. > My problem is that i have to modify the generated verilog(vhdl) code to > make it work. > Is myhdl meant to be like this or do i just have bad luck with this example? > I am asking because i am very new to myhdl and this is > acually my second example what i was trying. > Are you doing large projects with myhdl? > I am asking because i want to know if i should > dig more into myhdl or should i focus more on vhdl, when i do have > to modify vhdl afterwards anyway. > So what is your experiance? > Hi Günther, It is a bit of bad luck, you just hit a bug in the conversion of TristateSignal ... I essentially switched to MyHDL *completely*. For new code, of course I have to maintain some 10 years+ of VHDL coding. Most of my MyHDL modules are components I instantiate inside Qsys, so they tend to be not that large (not being small either). However I did a quite large project in MyHDL implementing a 'Support Vector Machine' -> http://de.wikipedia.org/wiki/Support_Vector_Machine, which produced 6703 lines of VHDL code. So yes, use MyHDL. One caveat: MyHDL is no silver bullet (there are no silver bullets ...). The design of RTL is very close to what you do in either VHDL or Verilog. But development is a factor quicker, essentially the simulation is where you gain most as you can use full Python to generate data for your testbenches and make these self-checking. E.g. in the Support Vector Machine module we could import a libsvm library to calculate the results to compare our simulation with. And to debug the RTL I wrote an integer version of it with lots of output written to the console to compare to the signals in the simulation window. I'm using Eclipse with PyDev for MyHDL editing/running and Impulse to view the simulation waveforms (under Windows 8.1) So once again, MyHDL is definitely preferable over VHDL or Verilog, and it is production ready. If a bug however shows up, there is a ready community to fix it. I already have a fix for the VHDL (others => 'Z') bug, but I have to inspect/fix the Verilog conversion too before I can issue a pull request to update the MyHDL 0.9 master development branch. Regards, Josy |
From: Günther S. <gue...@gm...> - 2015-05-19 06:30:09
|
Hello Josy, This conviced me, i will stay with myhdl, i think its really great. If there is a problem with tristate at the moment i can live with that, as i know now how to work around. Thanks a lot. Regards, guenther Am 17.05.2015 um 21:25 schrieb Josy Boelen: > Günther Stangassinger <guenther.stangassinger <at> gmx.net> writes: > >> Hello Josy, >> thank you for your answer. >> My problem is that i have to modify the generated verilog(vhdl) code > to >> make it work. >> Is myhdl meant to be like this or do i just have bad luck with this > example? >> I am asking because i am very new to myhdl and this is >> acually my second example what i was trying. >> Are you doing large projects with myhdl? >> I am asking because i want to know if i should >> dig more into myhdl or should i focus more on vhdl, when i do have >> to modify vhdl afterwards anyway. >> So what is your experiance? >> > > Hi Günther, > > It is a bit of bad luck, you just hit a bug in the conversion of > TristateSignal ... > > I essentially switched to MyHDL *completely*. For new code, of course I > have to maintain some 10 years+ of VHDL coding. > Most of my MyHDL modules are components I instantiate inside Qsys, so > they tend to be not that large (not being small either). However I did a > quite large project in MyHDL implementing a 'Support Vector Machine' -> > http://de.wikipedia.org/wiki/Support_Vector_Machine, which produced 6703 > lines of VHDL code. > > So yes, use MyHDL. > One caveat: MyHDL is no silver bullet (there are no silver bullets ...). > The design of RTL is very close to what you do in either VHDL or > Verilog. But development is a factor quicker, essentially the simulation > is where you gain most as you can use full Python to generate data for > your testbenches and make these self-checking. E.g. in the Support > Vector Machine module we could import a libsvm library to calculate the > results to compare our simulation with. And to debug the RTL I wrote an > integer version of it with lots of output written to the console to > compare to the signals in the simulation window. > I'm using Eclipse with PyDev for MyHDL editing/running and Impulse to > view the simulation waveforms (under Windows 8.1) > > So once again, MyHDL is definitely preferable over VHDL or Verilog, and > it is production ready. If a bug however shows up, there is a ready > community to fix it. I already have a fix for the VHDL (others => 'Z') > bug, but I have to inspect/fix the Verilog conversion too before I can > issue a pull request to update the MyHDL 0.9 master development branch. > > Regards, > > Josy > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Josy B. <jos...@gm...> - 2015-05-19 15:50:53
|
> Hello Josy, > > This conviced me, i will stay with myhdl, i think its really great. > If there is a problem with tristate at the moment i can live with that, > as i know now how to work around. > Thanks a lot. > Regards, > guenther > Welcome to our growing community! I submitted a Pull Request to fix that bug. One observation: in your code you are actually using a TriState pin to drive.read the I2C_SDAT. In reality the SDa pin in the I2C is an opendrain, with a pull-up in the circuit. So you can only drive it *low* and keep it tristated otherwise. Regards, Josy |
From: Christopher F. <chr...@gm...> - 2015-07-09 18:50:28
|
<snip> > > I submitted a Pull Request to fix that bug. Josy, Do you know which PR this was? Regards, Chris > One observation: in your code you are actually using a TriState pin to > drive.read the I2C_SDAT. In reality the SDa pin in the I2C is an > opendrain, with a pull-up in the circuit. So you can only drive it *low* > and keep it tristated otherwise. > > Regards, > > Josy |
From: Christopher F. <chr...@gm...> - 2015-07-09 20:58:30
|
On 7/9/2015 1:50 PM, Christopher Felton wrote: > <snip> >> >> I submitted a Pull Request to fix that bug. > > Josy, > > Do you know which PR this was? Think I found it #74: https://github.com/jandecaluwe/myhdl/pull/74 For reasons unknown (thus far) this breaks code that previously converted: https://gist.github.com/cfelton/6119313 Regards, Chris |
From: Josy B. <jos...@gm...> - 2015-07-10 07:21:33
|
Christopher Felton <chris.felton <at> gmail.com> writes: > Think I found it #74: > https://github.com/jandecaluwe/myhdl/pull/74 > > For reasons unknown (thus far) this breaks code > that previously converted: > https://gist.github.com/cfelton/6119313 MyHDL doesn't always like the ternary construct: 'sda_d.next = False if not sda_o else None' The PR #74 has, IMHO, no influence on the conversion of that construct. I have seen some of these ternary statements fail, and some not ... Also see issue #86 Regards, Josy |