*Summary* - 0:05: The streamer starts her second live stream, hoping to learn from the mistakes she made in her first live stream. - 0:31: She is using ethernet and starts running a simulation. - 1:06: From her last live stream, she has learned some lessons which she plans to apply in this session. - 1:32: She begins reorganizing a file in order to improve its structure and enhance its reusability. - 2:27: The file in question is an Ethernet packet generator, a topic that will be covered in a future video. - 2:42: She has identified an issue of getting distracted by comments and plans to manage this by creating a list of recommendations. - 2:56: She begins making a list of all her comment recommendations for future reference. - 3:34: A comment suggests making a video on how to implement zinc audio with pet Linux. - 5:20: She resumes her work, focusing on not getting too distracted by the comments. - 5:32: In response to a comment, she reveals that she lives in South Africa. - 6:20: She plans on modifying the Ethernet packet generator to have an axi interface. - 6:42: She explains that the generator essentially adds headers to data. - 7:54: She plans on creating a chain of modules where each module does a different part of the packet creation process. - 9:26: She discusses adding a fifo (First In, First Out) at the end of the state machine to improve flow control. - 10:16: She further explains that the fifo allows her to bypass the ready valid handshake, ensuring that the fifo has space before running the state machine. - 11:25: She decides to create an axi stream fifo that can contain at least two packets. - 11:46: She considers the size of the fifo, deciding it needs to be at least 1,500 bytes. - 12:44: She creates the fifo and plans to use it to handle the axi handshaking on the output of the module. - 13:33: She considers whether the fifo can have different input and output widths to handle different types of interfaces. - 14:38: However, she decides not to implement this feature as it's not currently needed for the code. - 14:59: She briefly explains the confusion between 'sources' and 'scope' in Vivado software, clarifying that 'scope' is specifically for simulation. - The user is explaining the functionalities and naming conventions in a simulation environment around 15:42. - Around 16:24, the user mentions that some signals may appear empty in the simulation if they haven't been rerun after being moved. - The user advises on choosing distinct names for entities, such as two "axi_data_fifo" created, to avoid confusion around 17:16. - The user shows how to use instantiation templates for an IP module at 17:28. - Emphasizes the preference for using EMAC to automatically beautify code around 18:26. - The user has renamed signals following a certain naming convention around 19:58. - User creates a programmable 'full' to ensure there is enough space in their fifo for a full packet around 21:50. - The user emphasizes the importance of using descriptive names for signals at around 24:20. - The user has implemented a system of conditions in their state machines to control the transition of states around 27:40. - The user utilizes two case statements in their code, one for decision-making and the other for defining the value of signals in each state around 29:26. - Around 30:05, the user is adding a 'last' signal and deciding its value for each state. - 30:45 The speaker discusses programming a state machine which allows visibility of the current and next states. - 32:23 They emphasize the combinatorial nature of the state machine, facilitating decisions regarding what state they'll go into next. - 32:48 The state machine's architecture allows the speaker to see both their current state and their predicted next state. - 33:19 They point out that without a combinatorial next state/current state, one would always be working one clock cycle behind. - 33:45 The speaker mentions a paper about State machines and its processes. - 35:09 The speaker discusses running a simulation to test the state machine. - 43:29 The speaker also discusses the use of a divider and a state counter in the state machine. - 45:51 The state counter is useful to keep track of how long you're in each state and allows the speaker to predict how long they'll be in every state. - 48:11 The speaker mentions the importance of setting up signals properly to facilitate smooth state transitions. - 48:31: The speaker is working with a code that deals with state transitions in a state machine. - 48:37: They are particularly interested in transitions out of the 'frame check sequence' state, which are signaled by a high value. - 50:03: The speaker likes that this setup is very clear in signaling their intentions in the code. - 50:19: They emphasize the importance of code being easily understandable by other humans, not just optimized for the synthesis tool. - 52:11: They encounter an issue with an output width that needs to be 8 bits instead of 2. This is due to the 'fifo' output and the output width being the same. - 55:54: The speaker resolves the issue by avoiding the shift operation when the output width and the 'fifo' width are the same. - 58:15: They then confirm that the adjustment has worked properly by running a simulation. - 59:30: The speaker concludes by outlining some future adjustments: they want to add more test cases with different data lengths and plan to modify their packet generation process. Disclaimer: I used the transcript. GPT4 and a lot of copy and paste.
Hi Stacey, Thanks for your videos. They are amazing. You have a lot of expertise. I also use the 3 state machine method. Including the tricks of checking that the next state is not equal to current state. I believe that if you place that IF inside the state machine process, you dont need to check if the current state is State X as you are already placing the code in the section corresponding to state X. I hope that you understand what I mean.
*Summary*
- 0:05: The streamer starts her second live stream, hoping to learn from the mistakes she made in her first live stream.
- 0:31: She is using ethernet and starts running a simulation.
- 1:06: From her last live stream, she has learned some lessons which she plans to apply in this session.
- 1:32: She begins reorganizing a file in order to improve its structure and enhance its reusability.
- 2:27: The file in question is an Ethernet packet generator, a topic that will be covered in a future video.
- 2:42: She has identified an issue of getting distracted by comments and plans to manage this by creating a list of recommendations.
- 2:56: She begins making a list of all her comment recommendations for future reference.
- 3:34: A comment suggests making a video on how to implement zinc audio with pet Linux.
- 5:20: She resumes her work, focusing on not getting too distracted by the comments.
- 5:32: In response to a comment, she reveals that she lives in South Africa.
- 6:20: She plans on modifying the Ethernet packet generator to have an axi interface.
- 6:42: She explains that the generator essentially adds headers to data.
- 7:54: She plans on creating a chain of modules where each module does a different part of the packet creation process.
- 9:26: She discusses adding a fifo (First In, First Out) at the end of the state machine to improve flow control.
- 10:16: She further explains that the fifo allows her to bypass the ready valid handshake, ensuring that the fifo has space before running the state machine.
- 11:25: She decides to create an axi stream fifo that can contain at least two packets.
- 11:46: She considers the size of the fifo, deciding it needs to be at least 1,500 bytes.
- 12:44: She creates the fifo and plans to use it to handle the axi handshaking on the output of the module.
- 13:33: She considers whether the fifo can have different input and output widths to handle different types of interfaces.
- 14:38: However, she decides not to implement this feature as it's not currently needed for the code.
- 14:59: She briefly explains the confusion between 'sources' and 'scope' in Vivado software, clarifying that 'scope' is specifically for simulation.
- The user is explaining the functionalities and naming conventions in a simulation environment around 15:42.
- Around 16:24, the user mentions that some signals may appear empty in the simulation if they haven't been rerun after being moved.
- The user advises on choosing distinct names for entities, such as two "axi_data_fifo" created, to avoid confusion around 17:16.
- The user shows how to use instantiation templates for an IP module at 17:28.
- Emphasizes the preference for using EMAC to automatically beautify code around 18:26.
- The user has renamed signals following a certain naming convention around 19:58.
- User creates a programmable 'full' to ensure there is enough space in their fifo for a full packet around 21:50.
- The user emphasizes the importance of using descriptive names for signals at around 24:20.
- The user has implemented a system of conditions in their state machines to control the transition of states around 27:40.
- The user utilizes two case statements in their code, one for decision-making and the other for defining the value of signals in each state around 29:26.
- Around 30:05, the user is adding a 'last' signal and deciding its value for each state.
- 30:45 The speaker discusses programming a state machine which allows visibility of the current and next states.
- 32:23 They emphasize the combinatorial nature of the state machine, facilitating decisions regarding what state they'll go into next.
- 32:48 The state machine's architecture allows the speaker to see both their current state and their predicted next state.
- 33:19 They point out that without a combinatorial next state/current state, one would always be working one clock cycle behind.
- 33:45 The speaker mentions a paper about State machines and its processes.
- 35:09 The speaker discusses running a simulation to test the state machine.
- 43:29 The speaker also discusses the use of a divider and a state counter in the state machine.
- 45:51 The state counter is useful to keep track of how long you're in each state and allows the speaker to predict how long they'll be in every state.
- 48:11 The speaker mentions the importance of setting up signals properly to facilitate smooth state transitions.
- 48:31: The speaker is working with a code that deals with state transitions in a state machine.
- 48:37: They are particularly interested in transitions out of the 'frame check sequence' state, which are signaled by a high value.
- 50:03: The speaker likes that this setup is very clear in signaling their intentions in the code.
- 50:19: They emphasize the importance of code being easily understandable by other humans, not just optimized for the synthesis tool.
- 52:11: They encounter an issue with an output width that needs to be 8 bits instead of 2. This is due to the 'fifo' output and the output width being the same.
- 55:54: The speaker resolves the issue by avoiding the shift operation when the output width and the 'fifo' width are the same.
- 58:15: They then confirm that the adjustment has worked properly by running a simulation.
- 59:30: The speaker concludes by outlining some future adjustments: they want to add more test cases with different data lengths and plan to modify their packet generation process.
Disclaimer: I used the transcript. GPT4 and a lot of copy and paste.
thank you so much !!!
So interesting , thank you for u streaming and work))) I will wait next video and stream
Hi Stacey,
Thanks for your videos. They are amazing. You have a lot of expertise.
I also use the 3 state machine method.
Including the tricks of checking that the next state is not equal to current state.
I believe that if you place that IF inside the state machine process, you dont need to check if the current state is State X as you are already placing the code in the section corresponding to state X.
I hope that you understand what I mean.
Superb! Thanks 👍
You are the best, please, upload this video soon. I missed the stream):
Hi Stacey, thanks for the content. Could you explain one day your emacs config?
Where can I follow you so i can know when you stream and be up-to-date with your work?